I would like to come up again with an issue already discussed in some
details.
What stops us from (also) having

str4 = str1.left(5) ~ str2[3..4] ~ str3.right(6);

instead of

str4 = str1[0..4] ~ str2[3..4] ~ str3[str3.length-6..str3.length-1];

For me it seems much more intuitive, and easy enough to implement. Using the "right" property can even be faster than slicing, due to the absence of multiple indirections.

Yours,
Sandor

That's not a bad idea!

We could also have some kind of .mid property that has a more natural syntax than for array slicing.  Such as pos and count, and count would maybe be rangechecked against the available size.

You could call the .left property .first or the .right property .last also, to make it more generic and intuitive (not all strings read "left to right" especially in Chinese etc)

Sean


"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:agec01$2alu$1@digitaldaemon.com...
> I would like to come up again with an issue already discussed in some
> details.
> What stops us from (also) having
>
> str4 = str1.left(5) ~ str2[3..4] ~ str3.right(6);
>
> instead of
>
> str4 = str1[0..4] ~ str2[3..4] ~ str3[str3.length-6..str3.length-1];
>
> For me it seems much more intuitive, and easy enough to implement. Using
the
> "right" property can even be faster than slicing, due to the absence of multiple indirections.
>
> Yours,
> Sandor

Looks like a good idea.  I've always like how that could be done similarly in VB. It should be part of the standard.

Of coarse you could always invent your own and write it like....

str4 = left(str1, 5) ~ str2[3..4] ~ right(str3, 6);

On a slightly different note.
Perhaps there could also be a way of creating your own attributes/properties
for arrays (or any type for that matter).  Perhaps that could be something
included in Generics when it's implemented. Or perhaps we should just stick
to using classes.

Hmmm....

Or perhaps the property (getters and setters) syntax in D could be
extended...

char[] left(char[] in String, int in value) {...}

Would be equate to...

    string2 = left(string, 5);
and ...
    string2 = string.left(5);

And the setter (if needed)

    void left(char[] in String, int in value) {...}

    string.left(5) = "The first 5 letters of this sentence.";

Or something along those lines...(I sense problems with what I just wrote).


"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:agec01$2alu$1@digitaldaemon.com...
> I would like to come up again with an issue already discussed in some
> details.
> What stops us from (also) having
>
> str4 = str1.left(5) ~ str2[3..4] ~ str3.right(6);
>
> instead of
>
> str4 = str1[0..4] ~ str2[3..4] ~ str3[str3.length-6..str3.length-1];
>
> For me it seems much more intuitive, and easy enough to implement. Using
the
> "right" property can even be faster than slicing, due to the absence of multiple indirections.
>
> Yours,
> Sandor
>
>

"anderson" <anderson@firestar.com.au> wrote in message news:agga0i$1mop$1@digitaldaemon.com...
> Looks like a good idea.  I've always like how that could be done similarly in VB. It should be part of the standard.
>
> Of coarse you could always invent your own and write it like....
>
> str4 = left(str1, 5) ~ str2[3..4] ~ right(str3, 6);

You can not. Not without templates, or macros.
I would not define a separate "left" function for each array type I could
possibly use. No way.

> On a slightly different note.
> Perhaps there could also be a way of creating your own
attributes/properties
> for arrays (or any type for that matter).  Perhaps that could be something included in Generics when it's implemented. Or perhaps we should just
stick
> to using classes.

The problem is, that you are unable to mimic the behaviour of built-in types
(due to lack of operator overload), so you can not make a separate class
which seems to be the extension of the built-in array. (see the vector
template in c++ STL).
I can think of several other operations on arrays, which could happily fit
with the member function syntax. Such as insertion.
Yes I know you can "emulate" insertion with slicing. The code is ugly, and
dangerously redundant. I have a bet that the underlying code is slower that
the one which could be implemented for insertion.
Now if I, or a general library provider, want to make an array which has
insertion as a member function, I need to say goodbye to the [] operator.
Too bad.

> Hmmm....
>
> Or perhaps the property (getters and setters) syntax in D could be
> extended...
>
> char[] left(char[] in String, int in value) {...}

You mean something like:
anyType[] left(anyType[] in Array, int in value) { ... }

>
> Would be equate to...
>
>     string2 = left(string, 5);
> and ...
>     string2 = string.left(5);

That's interesting. It rather seems to me an extension of the function call
sytax. A rather promissing extension.
That means you can extend any class with member functions of a special kind:
- They can only access public members
- They are public
- They cannot be called based on context. (you allways need to specify the
object instance)

Appart from the last restriction it is like deriving a class from the base class and giving it the same name. Several problems could be solved elegantly with this extension.

Another idea based on this one: I would be happy to see a special access keyword "shallow" for member functions. Such member function could only access public members of the same class. It has to be public of course. It is usefull for similar reasons than the private and protected members. To help modularity. I could provide examples if you need.

> And the setter (if needed)
>
>     void left(char[] in String, int in value) {...}

No. It differs only in return value type.

>
>     string.left(5) = "The first 5 letters of this sentence.";
>
> Or something along those lines...(I sense problems with what I just
wrote).

That expression can be evaluated as replacing the first 5 array elements with any number of other array elements; moving the rest of the array if needed. But I don't think that this is really necessary. I would be happy with only read-only properties for this time.

Yours,
Sandor

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:agm9pc$1ati$1@digitaldaemon.com...
>
> "anderson" <anderson@firestar.com.au> wrote in message news:agga0i$1mop$1@digitaldaemon.com...
> > Looks like a good idea.  I've always like how that could be done
similarly
> > in VB. It should be part of the standard.
> >
> > Of coarse you could always invent your own and write it like....
> >
> > str4 = left(str1, 5) ~ str2[3..4] ~ right(str3, 6);
>
> You can not. Not without templates, or macros.
> I would not define a separate "left" function for each array type I could
> possibly use. No way.

What about void (void * for arrays)? Or is that depreciated for variable use
in D? Anyway I'm assumping D will have generics in the future (2.0).

> > On a slightly different note.
> > Perhaps there could also be a way of creating your own
> attributes/properties
> > for arrays (or any type for that matter).  Perhaps that could be
something
> > included in Generics when it's implemented. Or perhaps we should just
> stick
> > to using classes.
>
> The problem is, that you are unable to mimic the behaviour of built-in
types
> (due to lack of operator overload), so you can not make a separate class
> which seems to be the extension of the built-in array. (see the vector
> template in c++ STL).

Parhaps there could be a way to extend types into classes (and template
classes) and then use them.

> I can think of several other operations on arrays, which could happily fit
> with the member function syntax. Such as insertion.
> Yes I know you can "emulate" insertion with slicing. The code is ugly, and
> dangerously redundant. I have a bet that the underlying code is slower
that
> the one which could be implemented for insertion.
> Now if I, or a general library provider, want to make an array which has
> insertion as a member function, I need to say goodbye to the [] operator.
> Too bad.
> > Hmmm....
> >
> > Or perhaps the property (getters and setters) syntax in D could be
> > extended...
> >
> > char[] left(char[] in String, int in value) {...}
>
> You mean something like:
> anyType[] left(anyType[] in Array, int in value) { ... }

anyType[] left(void[] in Array, int in value) { ... }

Yeah, but In some cases you'd want to be specific.

> >
> > Would be equate to...
> >
> >     string2 = left(string, 5);
> > and ...
> >     string2 = string.left(5);
>
> That's interesting. It rather seems to me an extension of the function
call
> sytax. A rather promissing extension.
> That means you can extend any class with member functions of a special
kind:
> - They can only access public members
> - They are public
> - They cannot be called based on context. (you allways need to specify the
> object instance)
>
> Appart from the last restriction it is like deriving a class from the base class and giving it the same name. Several problems could be solved elegantly with this extension.
>
> Another idea based on this one: I would be happy to see a special access keyword "shallow" for member functions. Such member function could only access public members of the same class. It has to be public of course. It is usefull for similar reasons than the private and protected members. To help modularity. I could provide examples if you need.

No, I get the idea. It seems like a good idea, because many times you have to much class information to deal with. The only disadvantage is that if used improperly, code reuse could be sacificed. It should also apply to member variables, just to make things complete.

>
> > And the setter (if needed)
> >
> >     void left(char[] in String, int in value) {...}
>
> No. It differs only in return value type.

Which is something I think D should have if you refur to my previous disscussions about using cast() with the return type.

Actually, that code wouldn't have worked (no pointer to what we are
modifying). I relize that (that's way I said I sense problems). Parhaps...

void left(int in value, char[] in String, char[] inout String) {...}

Would be more apropriate. But still there are problems because how will the compiler reconise it from a differn't type getter/setter type?

> >
> >     string.left(5) = "The first 5 letters of this sentence.";
> >
> > Or something along those lines...(I sense problems with what I just
> wrote).
>
> That expression can be evaluated as replacing the first 5 array elements with any number of other array elements; moving the rest of the array if needed.

Exactly.

> But I don't think that this is really necessary. I would be happy with only read-only properties for this time.

I would also but I do like things to be complete, and read/write seems more complete to me.

> Yours,
> Sandor
>

> What about void (void * for arrays)? Or is that depreciated for variable
use
> in D? Anyway I'm assumping D will have generics in the future (2.0).
>

I relize that void * brings in a list of other problems (such as size
determination).

"anderson" <anderson@firestar.com.au> wrote in message news:agoc15$17v7$1@digitaldaemon.com...
>
> > The problem is, that you are unable to mimic the behaviour of built-in
types
> > (due to lack of operator overload), so you can not make a separate class
> > which seems to be the extension of the built-in array. (see the vector
> > template in c++ STL).
>
> Parhaps there could be a way to extend types into classes (and template
> classes) and then use them.

Maybe if you derive a struct from a basic type, you inherit all the operators that apply to the basic type and can then override them?  Perhaps in method syntax (named) form (such as "add" instead of "+")

I can think of a few uses for operator overloading where you just want the operators for the basic type without the actual storage for it.  And sometimes you want extra operators that the type doesn't ordinarily have. Not to mention possibly operators that *no* builtin types possess.

Sean

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agoqpa$23p4$1@digitaldaemon.com...
> "anderson" <anderson@firestar.com.au> wrote in message news:agoc15$17v7$1@digitaldaemon.com...
> >
> > > The problem is, that you are unable to mimic the behaviour of built-in
> types
> > > (due to lack of operator overload), so you can not make a separate
class
> > > which seems to be the extension of the built-in array. (see the vector
> > > template in c++ STL).
> >
> > Parhaps there could be a way to extend types into classes (and template
> > classes) and then use them.
>
> Maybe if you derive a struct from a basic type, you inherit all the operators that apply to the basic type and can then override them?
Perhaps
> in method syntax (named) form (such as "add" instead of "+")
>
> I can think of a few uses for operator overloading where you just want the operators for the basic type without the actual storage for it.  And sometimes you want extra operators that the type doesn't ordinarily have. Not to mention possibly operators that *no* builtin types possess.
>
> Sean
>

 Sounds like a good idea. How would the syntax look? Keep the brain storming
comming.

--I remember java did it using clases (ie the integer class). I know that it's methods were ineffecient and unclean, but that fact that they implemented it must of ment that there was some use for it.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:agoqpa$23p4$1@digitaldaemon.com...
>
<SNIP>
>
> Maybe if you derive a struct from a basic type, you inherit all the operators that apply to the basic type and can then override them?
Perhaps
> in method syntax (named) form (such as "add" instead of "+")
>
> I can think of a few uses for operator overloading where you just want the operators for the basic type without the actual storage for it.  And sometimes you want extra operators that the type doesn't ordinarily have. Not to mention possibly operators that *no* builtin types possess.
>
> Sean
>

The best thing to me still seems to be giving Object
a few extra methods, such as add(), sub(), mul()
and div() and map the operators to calls to these
functions. This is already done for == I believe?

The standard implementation of these methods in Object
would be to just throw an exception, while descendant
classes may choose to override this behaviour.
The problem is you would also need to have overloaded
versions of these methods for the basic types, but
that just means Object will have a lot of methods, not
a real serious problem. I think the basic types are
pretty fixed?

For the operator + you would have:

class Object
{
   // .....
   Object add (Object param);
   Object add (int param);
   Object add (extended param);
   Object add (char param);
   Object add (complex param);

   // Ofcourse the ideal form would be with templates
   <template T>
   Object add (T param);
}

So I think this is something for D 2.0
What problems do you see with an approach such as
this? Any insights?


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

> The best thing to me still seems to be giving Object
> a few extra methods, such as add(), sub(), mul()
> and div() and map the operators to calls to these
> functions. This is already done for == I believe?
>
> The standard implementation of these methods in Object
> would be to just throw an exception, while descendant
> classes may choose to override this behaviour.
> The problem is you would also need to have overloaded
> versions of these methods for the basic types, but
> that just means Object will have a lot of methods, not
> a real serious problem. I think the basic types are
> pretty fixed?
>
> For the operator + you would have:
>
> class Object
> {
>    // .....
>    Object add (Object param);
>    Object add (int param);
>    Object add (extended param);
>    Object add (char param);
>    Object add (complex param);
>
>    // Ofcourse the ideal form would be with templates
>    <template T>
>    Object add (T param);
> }
>
> So I think this is something for D 2.0
> What problems do you see with an approach such as
> this? Any insights?
>

Yes, that's pretty simular to C++ but with nicer syntax. We were discussing being able to add "D properties" to standard data types and arrays.

so,

class Object : int
{
...
}

or as Sean suggested use,

struct Object : int
{

}

Also you should add app (append ~) to your list.

> --
> Stijn
> OddesE_XYZ@hotmail.com
> http://OddesE.cjb.net
> _________________________________________________
> Remove _XYZ from my address when replying by mail
>
>
>