I think the point of properties is to make them look and feel just like variables.  Templates can leverage this.

One of the things I don't like about Sather is all the rules about how you have to capitalize the identifiers.  I'd much rather the language be case agnostic.

Sean

"Jonathan Andrew" <Jonathan_member@pathlink.com> wrote in message news:b0873a$2ct0$1@digitaldaemon.com...
> Maybe as a matter of style, the programmer should capitalize the first
letter
> of the property to distinguish it from regular public variables. Perhaps that should go in the style guide. (Once properties are implemented.)

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b08h6l$2isd$1@digitaldaemon.com...
> Why does everything have to be so damned explicit?!!
>
> And how is "x.setY(x.getY()+10)" any more understandable than "x.y+=10"??
>

it depends what x is; to me

"x.y+=10" => or x.y.incBy( 10 )

operator += rather than set with get op+ 10

So write x.y = x.y + 10 then.  Still better than get and set with all the parenthesis.

Sean

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b08rp1$2nqf$1@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b08h6l$2isd$1@digitaldaemon.com...
> > Why does everything have to be so damned explicit?!!
> >
> > And how is "x.setY(x.getY()+10)" any more understandable than
"x.y+=10"??
> >
>
> it depends what x is; to me
>
> "x.y+=10" => or x.y.incBy( 10 )
>
> operator += rather than set with get op+ 10

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b09jo3$60l$1@digitaldaemon.com...
> So write x.y = x.y + 10 then.  Still better than get and set with all the parenthesis.
>

agree, I was answering the question
>>> And how is "x.setY(x.getY()+10)" any more understandable than
>>> "x.y+=10"??


and it depends on your view of what D is; if D is a replacement to C/C++ and
other algo60 derived langs which should be more powerful than any that have
come before then allowing x.y += 10; to be x.y = x.y + 10 which is
x.y.set( x.y.get().add( 10 ) );
as long as its in the docs, then fine;

however if D is to be a C/C++/C#/Java styled language which gives you the power of C but with less pitfalls for the unwary and better compile checks and more builtin feature to ease programming at the expence of some features which would require the programmer knowing about the inner workings of the compiler and its behaviour in given situations. then I say operator overloading is a bad feature so += would not be allowed anyway gettors/settors are not a bad feature as they ease the code effectivly the only overloaded operator is '='

as with all these features we all have a different view, I for instance
dislike builtin hashtables/assoc arrays and think
that they should be a templated class which has an indexed getor/setor (like
indexed props in delphi)
template map(F, T) {
    class hashtable {
        get T this[F key] { .... }
        set  this[F key](T value ) { ... }
    }
    // other types of map ... etc
    class searchablesortedbinarytree {
    }
}
so instead of
    int[char*] foo;
you'd use something like
    instance map( char *, int ).hashtable foo;

and I'd like virtual static and virtual constructor from delphi too;
    so to create foo would be
    foo.new( params );  (like eiffel I believe operator !! );
    not
    instance map( char *, int ).hashtable foo = new instance map( char *,
int ).hashtable( params );
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b08rp1$2nqf$1@digitaldaemon.com...
> >
> > "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b08h6l$2isd$1@digitaldaemon.com...
> > > Why does everything have to be so damned explicit?!!
> > >
> > > And how is "x.setY(x.getY()+10)" any more understandable than
> "x.y+=10"??
> > >
> >
> > it depends what x is; to me
> >
> > "x.y+=10" => or x.y.incBy( 10 )
> >
> > operator += rather than set with get op+ 10
>
>

"Andy Friesen" <andy@ikagames.com> escreveu na mensagem news:b07pab$25t5$1@digitaldaemon.com...
> If you want to be *really* explicit, you can use assembly. ;)  I prefer to abstract things when it makes life easier.
>
> Having properties (the C# term for getter/setters) perform logic as well as assign values is the whole point.  Checking bounds, or relaying to an external API along with an assignment is a useful idiom that, like anything, can be misused.  It's just a matter of whether it's easy enough to use properly, and worth the potential for "evil."
>
> In the case of properties, I would say that they're well worth it.
>
> Paul Stanton wrote:
> > yeah, i c ur point.
> >
> > but personally, i would take the hit for the following reason... By nature, getters and setters dont have to be simple getters and
setters. they
> > can (some cases should not) contain logic. therefore, i would want it
explicit
> > that i was using programmer defined methods ("x.setY(x.getY()+10)"),
rather then
> > an operator ("x.y+=10").
> >
> > In article <b07ndv$24tn$1@digitaldaemon.com>, Andy Friesen says...
> >
> >>It's a simple matter of readability.  Getters/setters look a lot nicer than get/set methods.  Which do you prefer:
> >>
> >> window.SetWidth(window.GetWidth() + 10)
> >>or
> >> window.Width += 10;
> >>
> >>Another example is a rectangle struct that exposes x, y, width, height, top, left, bottom, and right properties all at once, and allows all to be read or written as suits the situation at hand.
> >>
> >>There's also nice (though arguably naughty) tricks like making a variable public, then later wrapping it up into a getter/setter when it becomes necessary, without changing the public interface.
> >>
> >>You do have a point; getter/setters are just syntactic sugar.  But they're kind of sugar that helps make a lot of things simpler and more intuitive, and just a Very Good Thing to have in general.
> >>
> >>Paul Stanton wrote:
> >>
> >>>not sure why any of this needs to be done automatic anyway. y not just
(like
> >>>java does) leave it all to be explicitly defined by programmer?
> >>>
> >>>
> >>
> >
> >
>

Hi,

    Dumb data-holders with properties are quick to develop, but awful in
good OO design. This kind of programming leads to proliferation of data
objects and controller objects, as in most GUI APIs available today. Sure
window.width += 10 is better than window.setWidth(window.getWidth() + 10),
but what we're looking for are method to say. window.increaseBy(0, 10) or
something like that.

    Best regards,
    Daniel Yokomiso.

"Life may have no meaning. Or even worse, it may have a meaning of which I
disapprove."
- Ashleigh Brilliant"Andy Friesen" <andy@ikagames.com> escreveu na mensagem
news:b07pab$25t5$1@digitaldaemon.com...
> If you want to be *really* explicit, you can use assembly. ;)  I prefer to abstract things when it makes life easier.
>
> Having properties (the C# term for getter/setters) perform logic as well as assign values is the whole point.  Checking bounds, or relaying to an external API along with an assignment is a useful idiom that, like anything, can be misused.  It's just a matter of whether it's easy enough to use properly, and worth the potential for "evil."
>
> In the case of properties, I would say that they're well worth it.
>
> Paul Stanton wrote:
> > yeah, i c ur point.
> >
> > but personally, i would take the hit for the following reason... By nature, getters and setters dont have to be simple getters and
setters. they
> > can (some cases should not) contain logic. therefore, i would want it
explicit
> > that i was using programmer defined methods ("x.setY(x.getY()+10)"),
rather then
> > an operator ("x.y+=10").
> >
> > In article <b07ndv$24tn$1@digitaldaemon.com>, Andy Friesen says...
> >
> >>It's a simple matter of readability.  Getters/setters look a lot nicer than get/set methods.  Which do you prefer:
> >>
> >> window.SetWidth(window.GetWidth() + 10)
> >>or
> >> window.Width += 10;
> >>
> >>Another example is a rectangle struct that exposes x, y, width, height, top, left, bottom, and right properties all at once, and allows all to be read or written as suits the situation at hand.
> >>
> >>There's also nice (though arguably naughty) tricks like making a variable public, then later wrapping it up into a getter/setter when it becomes necessary, without changing the public interface.
> >>
> >>You do have a point; getter/setters are just syntactic sugar.  But they're kind of sugar that helps make a lot of things simpler and more intuitive, and just a Very Good Thing to have in general.
> >>
> >>Paul Stanton wrote:
> >>
> >>>not sure why any of this needs to be done automatic anyway. y not just
(like
> >>>java does) leave it all to be explicitly defined by programmer?
> >>>
> >>>
> >>
> >
> >
>

Hi,

    Dumb data-holders with properties are quick to develop, but awful in
good OO design. This kind of programming leads to proliferation of data
objects and controller objects, as in most GUI APIs available today. Sure
window.width += 10 is better than window.setWidth(window.getWidth() + 10),
but what we're looking for are method to say. window.increaseBy(0, 10) or
something like that.

    Best regards,
    Daniel Yokomiso.

"Life may have no meaning. Or even worse, it may have a meaning of which I
disapprove."
- Ashleigh Brilliant

Sean L. Palmer wrote:
> Why does everything have to be so damned explicit?!!
> 
> And how is "x.setY(x.getY()+10)" any more understandable than "x.y+=10"??
> 
> The problem here is your preconceived notions of what programming is about.
> I for one do not want to be forced to be explicit about every little detail
> of execution.  Taken to the extreme that would eliminate *ALL* code reuse.
> 
> I *LIKE* the idea of the compiler understanding something more similar to my
> native language, instead of forcing me to use its alien computer tongue.
> 
> D has an opportunity here to "rewrite the rules" so to speak.  I'd carefully
> consider any artificial limitations.

Amen!

If you want, you can always write a code style document for your organization that bans such use of properties.  But if they aren't in the language, then NOBODY can use them, not even those who want to.



I'm in favor of allowing syntax sugar provided that it meets three requirements:
	* doesn't forbid using the low-level "old" style (for
	  performance or other reasons)
	* doesn't add overhead to all programs
	  even those that don't use the feature
	* doesn't make the compiler markedly harder to write



The truth is, if your properties are working sanely, then
	x.y += 10;
is VERY readable to the casual programmer.  The people who care about performance are the ones who will know the internals of the language and the compiler, and they will be intimately aware of the complexity hidden in that simple statement.  So why is this an pitfall-prone feature?

Russell Lewis <spamhole-2001-07-16@deming-os.org> writes:
> 	x.y += 10;
>
> is VERY readable to the casual programmer.  The people who care about performance are the ones who will know the internals of the language and the compiler, and they will be intimately aware of the complexity hidden in that simple statement.  So why is this an pitfall-prone feature?

By the way -- assuming there are some people who know the internals of the language in this newsgroup ;) -- what does "x.y += 10" mean?

By looking at it (by following the D documentation in "Operator
overloading") calls the method (or member function) addass(10); on the
value returned by x.y();

However, the effects of that call depend on whether y is an integral or struct type or a reference type, such as a class.  If it's a class, x.y() returns a reference to the object; but if it's, for example, an integer, x.y() returns a copy of it.  And in this case a "+= 10" is performed on a temporary value.

What actually _should_ happen is not to call .addass() but to first transform "x.y += 10" into "x.y = x.y + 10" (actually that is not enough but more on that later), which leads into calling of the gettor, followed by calling of the settor.

Am I wrong?  Or is this a problem?

-Antti

Antti Sykari wrote:
> Russell Lewis <spamhole-2001-07-16@deming-os.org> writes:
> 
>>	x.y += 10;
>>
>>is VERY readable to the casual programmer.  The people who care about
>>performance are the ones who will know the internals of the language
>>and the compiler, and they will be intimately aware of the complexity
>>hidden in that simple statement.  So why is this an pitfall-prone
>>feature?
> 
> 
> By the way -- assuming there are some people who know the internals of
> the language in this newsgroup ;) -- what does "x.y += 10" mean?
> 
> By looking at it (by following the D documentation in "Operator
> overloading") calls the method (or member function) addass(10); on the
> value returned by x.y();
> 
> However, the effects of that call depend on whether y is an integral
> or struct type or a reference type, such as a class.  If it's a class,
> x.y() returns a reference to the object; but if it's, for example, an
> integer, x.y() returns a copy of it.  And in this case a "+= 10" is
> performed on a temporary value.
> 
> What actually _should_ happen is not to call .addass() but to first
> transform "x.y += 10" into "x.y = x.y + 10" (actually that is not
> enough but more on that later), which leads into calling of the
> gettor, followed by calling of the settor.
> 
> Am I wrong?  Or is this a problem?
> 
> -Antti

I don't know if there is a spec yet.  In fact, I don't know that the += operator even works for gettors & settors yet.  My point, though, is that if and when that is implemented, the low-level performance freaks will certainly know what the spec is and how best to use it.

Personally, I think that yes,
	x.y += 10;
should expand to
	x.y = x.y + 10;
which would result in a call to the gettor, an add, and a call to the settor.

"Russell Lewis" <spamhole-2001-07-16@deming-os.org> escreveu na mensagem news:3E2EE2EF.4030109@deming-os.org...
> Antti Sykari wrote:
> > Russell Lewis <spamhole-2001-07-16@deming-os.org> writes:
> >
> >> x.y += 10;
> >>
> >>is VERY readable to the casual programmer.  The people who care about performance are the ones who will know the internals of the language and the compiler, and they will be intimately aware of the complexity hidden in that simple statement.  So why is this an pitfall-prone feature?
> >
> >
> > By the way -- assuming there are some people who know the internals of the language in this newsgroup ;) -- what does "x.y += 10" mean?
> >
> > By looking at it (by following the D documentation in "Operator
> > overloading") calls the method (or member function) addass(10); on the
> > value returned by x.y();
> >
> > However, the effects of that call depend on whether y is an integral or struct type or a reference type, such as a class.  If it's a class, x.y() returns a reference to the object; but if it's, for example, an integer, x.y() returns a copy of it.  And in this case a "+= 10" is performed on a temporary value.
> >
> > What actually _should_ happen is not to call .addass() but to first transform "x.y += 10" into "x.y = x.y + 10" (actually that is not enough but more on that later), which leads into calling of the gettor, followed by calling of the settor.
> >
> > Am I wrong?  Or is this a problem?
> >
> > -Antti
>
> I don't know if there is a spec yet.  In fact, I don't know that the += operator even works for gettors & settors yet.  My point, though, is that if and when that is implemented, the low-level performance freaks will certainly know what the spec is and how best to use it.
>
> Personally, I think that yes,
> x.y += 10;
> should expand to
> x.y = x.y + 10;
> which would result in a call to the gettor, an add, and a call to the
> settor.

"x.y += 10" is defined to call addass on whatever "x.y" gives to you. If its a primitive, like int, it'll check first if x.y is a valid lvalue, if not give a compiler error AFAIK. addass is targeted for performance reasons, so two 100 x 100 Matrices can be added without generating any temporary garbage. Anything different from that will require some kind of template expressions to be efficient. But this is only valid for "A += B". If you write "A += B + C + D"; you'll get intermediate garbage anyway.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.443 / Virus Database: 248 - Release Date: 10/1/2003