Sorry for the late.
It seems that in order to provide backward compatible APIs, we need such
kind of shim class. Roy, What is your final decision?
Sincerely Yours,
Lei Shi
----------
On Thu, Oct 25, 2012 at 1:21 PM, Roy Stogner <royst...@ices.utexas.edu>wrote:
>
> On Thu, 25 Oct 2012, Boyce Griffith wrote:
>
> Libraries like Eigen and Blitz++ use operator() for accessors rather than
>> operator[]. How horrible would it be to go ahead and change to
>> operator() when making this change to LibMeshNArray?
>>
>
> Hmmm... it would mean that we couldn't get away with starting with
> just a typedef, we'd actually have to build a basic shim class right
> from the start, and it would be much more of a pain in the neck for
> user codes to upgrade.
>
> On the other hand, if we did want to keep operator[] support around
> indefinitely and we end up with a target class that doesn't support
> it, that would mean we'd have to keep a shim class around
> indefinitely... *and* we'd make it much less convenient to use a
> different-semantic operator[] from the target class, e.g. the Blitz++
> component accessor.
>
> More opinions would be welcome; I'm not even sure what I'd prefer yet.
> ---
> Roy
>
------------------------------------------------------------------------------
WINDOWS 8 is here.
Millions of people. Your app in 30 days.
Visit The Windows 8 Center at Sourceforge for all your go to resources.
http://windows8center.sourceforge.net/
join-generation-app-and-make-money-coding-fast/
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
