Is there a chance to have [] overloaded in D?

cheers,
QUS

Yes. It needs to be done, I just haven't done it yet.

"QUS" <qus@go2.pl> wrote in message news:bhvgir$1ksk$1@digitaldaemon.com...
> Is there a chance to have [] overloaded in D?
>
> cheers,
> QUS
>
>

> "QUS" <qus@go2.pl> wrote in message news:bhvgir$1ksk$1@digitaldaemon.com...
>>Is there a chance to have [] overloaded in D?

Walter wrote:
> Yes. It needs to be done, I just haven't done it yet.

This needs consideration. What i mean: C++ makes it a real pain to define classes which behave as if they were multi-dimensional array - and D has been heading the same way. I think you should allow do define a method to resolve to an array access operator - with multiple parameters - not only integers so that hasharrays can be imitated. Then, we also need to distinguish between reads and writes.

Calling syntax would seem to cause the least ambiguity if it were pascal-like.

	myArray[1, 2, 3, "str"] = 5;
could resolve to:
	myArray.oparray_w(1, 2, 3, "str", 5);

	local = myArray[1, 2, 3, "str"];
could resolve to:
	myArray.oparray_r(1, 2, 3, "str");

Sather uses a_get and a_set, IIRC.

If the name is the same for both reads and writes, this results in ambiguity which would not allow to make array acesses by fewer parameters in some cases - like when you need an array to do further work on.

-eye

"Ilya Minkov" <midiclub@8ung.at> escreveu na mensagem news:bikq49$iar$1@digitaldaemon.com...
> > "QUS" <qus@go2.pl> wrote in message
news:bhvgir$1ksk$1@digitaldaemon.com...
> >>Is there a chance to have [] overloaded in D?
>
> Walter wrote:
>  > Yes. It needs to be done, I just haven't done it yet.
>
> This needs consideration. What i mean: C++ makes it a real pain to define classes which behave as if they were multi-dimensional array - and D has been heading the same way. I think you should allow do define a method to resolve to an array access operator - with multiple parameters - not only integers so that hasharrays can be imitated. Then, we also need to distinguish between reads and writes.
>
> Calling syntax would seem to cause the least ambiguity if it were pascal-like.
>
> myArray[1, 2, 3, "str"] = 5;
> could resolve to:
> myArray.oparray_w(1, 2, 3, "str", 5);
>
> local = myArray[1, 2, 3, "str"];
> could resolve to:
> myArray.oparray_r(1, 2, 3, "str");
>
> Sather uses a_get and a_set, IIRC.
>
> If the name is the same for both reads and writes, this results in ambiguity which would not allow to make array acesses by fewer parameters in some cases - like when you need an array to do further work on.
>
> -eye


There's also the issue with slices that are important to multi-dimensional arrays, like matrices, and strides (currently unavailable in D) which can both be represented by the [ ] operator. The Blitz++ <http://www.oonumerics.org/blitz/> library has good examples of this.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003

> This needs consideration. What i mean: C++ makes it a real pain to define classes which behave as if they were multi-dimensional array -

Check out the fixed_/frame_array_2/3/4d templates in STLSoft

It might have been a laborious task, but other than making some stupid indexing typos in development they weren't what I would call "a real pain"

Matthew Wilson wrote:
> Check out the fixed_/frame_array_2/3/4d templates in STLSoft

Ah, thanks. :) with its documentation i would never have found them if you didn't mention...

Well, they solve a problem of creating real multi-dimensional arrays, not objects or properties which *behave* as if they were an array, but would retrieve data from elsewhere, and store it elsewhere. This need not necesarily be in memory, it can be a database or whatever.

A look at the boost also gave a real array, but no fake multi-dimensional arrays. Nor does Blitz++ seem to.

> It might have been a laborious task, but other than making some stupid
> indexing typos in development they weren't what I would call "a real pain"

So laborous in fact, that one would think twice before doing them. A screen of code (proxies!) to make something work, which only needs 2 lines with decent language support?

It is the task of D, to make routine coding faster and easier, and besides to move most klugdy library parts into the core language to make using such features easier.

-eye

"Ilya Minkov" <webmaster@midiclub.de.vu> wrote in message news:bitlt7$1sib$1@digitaldaemon.com...
> Matthew Wilson wrote:
> > Check out the fixed_/frame_array_2/3/4d templates in STLSoft
>
> Ah, thanks. :) with its documentation i would never have found them if you didn't mention...

well, ahem, yes, the STLSoft documentation is not the best. I'd be interested in any specific thoughts you might have to improve it.

> Well, they solve a problem of creating real multi-dimensional arrays, not objects or properties which *behave* as if they were an array, but would retrieve data from elsewhere, and store it elsewhere. This need not necesarily be in memory, it can be a database or whatever.

This is an intriguing issue. I may well implement such a component for C++ in STLSoft. If you take a look at the current multidim arrays you can see that a higher order array's [] operator returns a proxy instance of a lower order array, e.g.

template<   ss_typename_param_k T
        ,   ss_size_t N0
        ,   ss_size_t N1
        ,   ss_typename_param_k P   =   do_construction<T>
        >
class frame_array_2d
{
     typedef frame_array_1d<T, N1, P>                        dimension_type;

       . . .

     dimension_type          operator [](index_type i0);
    const dimension_type    operator [](index_type i0) const;

so it would be a very small matter to allow user-calls to do the same thing on raw memory. If you think this is something worth having, and that would see real use, then I'll give it a go. (Although it will have to wait until the next release, which is lurking behind several higher-priority things.)

> > It might have been a laborious task, but other than making some stupid indexing typos in development they weren't what I would call "a real
pain"
>
> So laborous in fact, that one would think twice before doing them. A screen of code (proxies!) to make something work, which only needs 2 lines with decent language support?

Well I can see how the language could do that for us, but I'm concerned that we may put things in the language which, by virtue of being iceberged (most of the implementation is under the surface) implies safety, but yet relies on specific knowledge on the part of the coder that the compiler cannot validate. If, perhaps, we could cast some memory to a multi-dim array, then I think that would be fine.

>
> It is the task of D, to make routine coding faster and easier, and besides to move most klugdy library parts into the core language to make using such features easier.
>
> -eye
>

Matthew Wilson wrote:

> well, ahem, yes, the STLSoft documentation is not the best. I'd be
> interested in any specific thoughts you might have to improve it.

Hard to say... Well, it's not hard to say, docuemtation is just a very laborous work. :)
Boost gives a perfect, intuitive example on the documentation.

Now, looking at the STLSoft:
 * Modules are good. It would just be better to append short descriptions to all module names. I'd say one could make a flat list with anchors and descriptions right after the hierarchical list. Items of the hierarchical list could have a [Description]-named link to the items of that flat list.
 * Definitions which apply would be good to have handy. It is not necessarily immediately obvious what a "fixed array" and what a "frame array" is.

>>Well, they solve a problem of creating real multi-dimensional arrays,

> This is an intriguing issue. I may well implement such a component for C++
> in STLSoft. If you take a look at the current multidim arrays you can see
> that a higher order array's [] operator returns a proxy instance of a lower
> order array, e.g.

[snipped away template - i'm not good at reading, nor on writing such stuff...]

> so it would be a very small matter to allow user-calls to do the same thing
> on raw memory. If you think this is something worth having, and that would
> see real use, then I'll give it a go. (Although it will have to wait until
> the next release, which is lurking behind several higher-priority things.)

I don't think this is requiered very often. There are more groundbreaking features that could be taken care of. For example: is it possible to implement properties in C++ using templates? I have been searching for libraries, but i found none. The problem seems to be - that there is probably no sane way to find out, what object these operations are performed at... Can you confirm that or do you have any implementation ideas?

> Well I can see how the language could do that for us, but I'm concerned that
> we may put things in the language which, by virtue of being iceberged (most
> of the implementation is under the surface) implies safety, but yet relies
> on specific knowledge on the part of the coder that the compiler cannot
> validate. If, perhaps, we could cast some memory to a multi-dim array, then
> I think that would be fine.

I don't think i can follow... does the user have to keep anything specific in mind with such things? And i'm also not exactly sure i understand why it has to be complicated - this is yet another resolution of a syntactic sugar to certain methods?

-eye

Hmm. Some interesting thoughts.

May I beg a few days to think about them, as am being crushed with other deadlines atm.

btw, I your properties notion. I'll give that some thought, in fact some are happening already ... leave it with me. I do like a challenge. :)

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:bjar3l$28h0$1@digitaldaemon.com...
> Matthew Wilson wrote:
>
> > well, ahem, yes, the STLSoft documentation is not the best. I'd be interested in any specific thoughts you might have to improve it.
>
> Hard to say... Well, it's not hard to say, docuemtation is just a very
> laborous work. :)
> Boost gives a perfect, intuitive example on the documentation.
>
> Now, looking at the STLSoft:
>   * Modules are good. It would just be better to append short
> descriptions to all module names. I'd say one could make a flat list
> with anchors and descriptions right after the hierarchical list. Items
> of the hierarchical list could have a [Description]-named link to the
> items of that flat list.
>   * Definitions which apply would be good to have handy. It is not
> necessarily immediately obvious what a "fixed array" and what a "frame
> array" is.
>
> >>Well, they solve a problem of creating real multi-dimensional arrays,
>
> > This is an intriguing issue. I may well implement such a component for
C++
> > in STLSoft. If you take a look at the current multidim arrays you can
see
> > that a higher order array's [] operator returns a proxy instance of a
lower
> > order array, e.g.
>
> [snipped away template - i'm not good at reading, nor on writing such stuff...]
>
> > so it would be a very small matter to allow user-calls to do the same
thing
> > on raw memory. If you think this is something worth having, and that
would
> > see real use, then I'll give it a go. (Although it will have to wait
until
> > the next release, which is lurking behind several higher-priority
things.)
>
> I don't think this is requiered very often. There are more groundbreaking features that could be taken care of. For example: is it possible to implement properties in C++ using templates? I have been searching for libraries, but i found none. The problem seems to be - that there is probably no sane way to find out, what object these operations are performed at... Can you confirm that or do you have any implementation ideas?
>
> > Well I can see how the language could do that for us, but I'm concerned
that
> > we may put things in the language which, by virtue of being iceberged
(most
> > of the implementation is under the surface) implies safety, but yet
relies
> > on specific knowledge on the part of the coder that the compiler cannot validate. If, perhaps, we could cast some memory to a multi-dim array,
then
> > I think that would be fine.
>
> I don't think i can follow... does the user have to keep anything specific in mind with such things? And i'm also not exactly sure i understand why it has to be complicated - this is yet another resolution of a syntactic sugar to certain methods?
>
> -eye
>