Wed, 22 Jul 2009 16:20:36 -0700, Walter Bright thusly wrote:
> Jarrett Billingsley wrote:
>> Ha. Had D differed *too* much from C++, then we'd run the risk of
>> scaring off the C++ snobs simply because it wasn't familiar enough to
>> them.
>
> It's a good point. Radically different languages te
Rainer Deyke wrote:
Benji Smith wrote:
For my money, the best solution is a simple "property" keyword as a
function modifier. Only functions with the "property" modifier would be
allowed to pose as fields (getters called without parens, setters called
using assignment syntax). But, in all other
sclytrack wrote:
- How does it interact with inheritance? Can I override properties?
sure
Can I partially override properties (setter but not getter)?
C# no.
- Can I write a setter that accepts another type?
no
- Can I write a templated setter that accepts *all* types? If so, how?
Rainer Deyke wrote:
>> For my money, the best solution is a simple "property" keyword as a
>> function modifier. Only functions with the "property" modifier would be
>> allowed to pose as fields (getters called without parens, setters called
>> using assignment syntax). But, in all other respects,
On Mon, 27 Jul 2009 21:14:10 -0400, Rainer Deyke
wrote:
Benji Smith wrote:
For my money, the best solution is a simple "property" keyword as a
function modifier. Only functions with the "property" modifier would be
allowed to pose as fields (getters called without parens, setters called
usin
Andrei Alexandrescu Wrote:
> Might be because (a) we aren't getting our priorities right, (b) we
> ascribe more to properties than what the compiler really makes of them.
>
> At the end of the day, a property is a notational convenience. Instead
> of writing:
>
> obj.set_xyz(5);
> int a = obj.
"grauzone" wrote in message
news:h4lnpn$11...@digitalmars.com...
> grauzone wrote:
>> That said, it would be really convenient for mixed compile time/runtime
>> meta programming to be able to associate additional information to a
>> method or a field. Like marking a method as property. Java and
grauzone wrote:
That said, it would be really convenient for mixed compile time/runtime
meta programming to be able to associate additional information to a
method or a field. Like marking a method as property. Java and C# have
attribute syntax for this. This would be useful for reflection,
se
Wed, 22 Jul 2009 23:10:53 +0200, Michiel Helvensteijn wrote:
> * Tuples (no dedicated syntax, no parallel assignment, no non-flattening
> tuples without workarounds, no returning tuples)
I'm planning to write a DIP on better tuple support. Here is a brief
overview of my ideas. I think I'll blog
"Andrei Alexandrescu" wrote in message
news:h4l83a$27u...@digitalmars.com...
>
> Well I don't know what it is, so there might as well be some parens in
> there. It's all arbitrary after all. Syntax upon syntax upon syntax. Why
> do we need it?
>
> This looks like switch all over again :o).
>
W
Benji Smith wrote:
> For my money, the best solution is a simple "property" keyword as a
> function modifier. Only functions with the "property" modifier would be
> allowed to pose as fields (getters called without parens, setters called
> using assignment syntax). But, in all other respects, they
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
Nick Sabalausky wrote:
I can't be nice about this: Any programmer who has *any* aggrivation
learning any even remotely sane property syntax is an idiot, period.
They'd have to be incompetent to not be able to look at an example
like this:
// Fi
Bill Baxter wrote:
On Mon, Jul 27, 2009 at 2:24 PM, John C wrote:
Andrei Alexandrescu wrote:
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:h4kkn3$14p...@digitalmars.com...
But what I want is to come with a new design that adds minimum
aggravation on the learning programm
> - How does it interact with inheritance? Can I override properties?
sure
> Can I partially override properties (setter but not getter)?
C# no.
> - Can I write a setter that accepts another type?
no
> - Can I write a templated setter that accepts *all* types? If so, how?
wut?
> - Can I
On Mon, Jul 27, 2009 at 3:01 PM, Andrei
Alexandrescu wrote:
> Nick Sabalausky wrote:
>>
>> "Andrei Alexandrescu" wrote in message
>> news:h4l4nr$20u...@digitalmars.com...
Sure. My point is that with using standard method definition syntax
there's no need for even looking over an exa
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:h4l4nr$20u...@digitalmars.com...
Sure. My point is that with using standard method definition syntax
there's no need for even looking over an example.
So people are going to automagically just *know* to stick "opGet_" in front
Rainer Deyke wrote:
Nick Sabalausky wrote:
I can't be nice about this: Any programmer who has *any* aggrivation
learning any even remotely sane property syntax is an idiot, period. They'd
have to be incompetent to not be able to look at an example like this:
// Fine, I'll throw DRY away:
int
On Mon, 27 Jul 2009 17:24:06 -0400, John C wrote:
Which is why Steven Schveighoffer's is suggestion is the most pragmatic
so far. You just add a "property" attribute to a regular function
definition. (And it doesn't look ugly, unlike the opGet_/opSet_ idea.)
I'll note that I wasn't the fir
"Andrei Alexandrescu" wrote in message
news:h4l4nr$20u...@digitalmars.com...
>>
>> Sure. My point is that with using standard method definition syntax
>> there's no need for even looking over an example.
>
So people are going to automagically just *know* to stick "opGet_" in front
of the name
Nick Sabalausky wrote:
> I can't be nice about this: Any programmer who has *any* aggrivation
> learning any even remotely sane property syntax is an idiot, period. They'd
> have to be incompetent to not be able to look at an example like this:
>
> // Fine, I'll throw DRY away:
> int _width;
> i
On Mon, Jul 27, 2009 at 2:24 PM, John C wrote:
> Andrei Alexandrescu wrote:
>>
>> Nick Sabalausky wrote:
>>>
>>> "Andrei Alexandrescu" wrote in message
>>> news:h4kkn3$14p...@digitalmars.com...
But what I want is to come with a new design that adds minimum
aggravation on the learnin
Andrei Alexandrescu wrote:
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:h4kkn3$14p...@digitalmars.com...
But what I want is to come with a new design that adds minimum
aggravation on the learning programmer. If they know how to define a
method, they must know how to defi
Lutger:
> Oh yes, I remember being freaked out reading about the APL after that one:
> (~RâRâ.ÃR)/Râ1ââ³R
> (this finds all prime numbers from 1 to R in the APL)
I can't read that APL code, and Python code that does the same is more than
twice longer (and it may also be slower):
>>> n
Andrei Alexandrescu wrote:
> Lutger wrote:
>> python:
>> (x * x for x in xrange(10, 20) if x & 1)
>>
>> D as of now:
>> map!("a * a")( filter!("a & 1")( range!(10,20) ) )
>>
>> D with extension methods:
>> range!(10,20).filter!("a & 1").map!("a * a")
>>
>> Not too bad right?
>>
>> (the r
Andrei Alexandrescu wrote:
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:h4kkn3$14p...@digitalmars.com...
But what I want is to come with a new design that adds minimum
aggravation on the learning programmer. If they know how to define a
method, they must know how to defi
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:h4kkn3$14p...@digitalmars.com...
But what I want is to come with a new design that adds minimum aggravation
on the learning programmer. If they know how to define a method, they must
know how to define a property. None of that
bearophile wrote:
Lutger:
python:
(x * x for x in xrange(10, 20) if x & 1)
D as of now:
map!("a * a")( filter!("a & 1")( range!(10,20) ) )
D with extension methods:
range!(10,20).filter!("a & 1").map!("a * a")
Not too bad right?
It's not terrible, but it's far from being nice. String
Lutger wrote:
python:
(x * x for x in xrange(10, 20) if x & 1)
D as of now:
map!("a * a")( filter!("a & 1")( range!(10,20) ) )
D with extension methods:
range!(10,20).filter!("a & 1").map!("a * a")
Not too bad right?
(the range function is fictional, I forgot if and which one exists i
Lutger:
> python:
> (x * x for x in xrange(10, 20) if x & 1)
>
> D as of now:
> map!("a * a")( filter!("a & 1")( range!(10,20) ) )
>
> D with extension methods:
> range!(10,20).filter!("a & 1").map!("a * a")
>
> Not too bad right?
It's not terrible, but it's far from being nice. Strings
python:
(x * x for x in xrange(10, 20) if x & 1)
D as of now:
map!("a * a")( filter!("a & 1")( range!(10,20) ) )
D with extension methods:
range!(10,20).filter!("a & 1").map!("a * a")
Not too bad right?
(the range function is fictional, I forgot if and which one exists in
phobos)
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:h4kkn3$14p...@digitalmars.com...
While we're at it, let's just throw away for and foreach, after all, there
can't possibly be any point to those if you already have while! Why should
we give people new to D the aggrivation of h
"Andrei Alexandrescu" wrote in message
news:h4kkn3$14p...@digitalmars.com...
>
> But what I want is to come with a new design that adds minimum aggravation
> on the learning programmer. If they know how to define a method, they must
> know how to define a property. None of that property blah {
Lutger:
>I was referring to your suggestion of adding features to see how they pan out
>and then removing them, not any particular feature.<
Yes, there's a small contradiction there, because usually there's no a single
best solution to a problem, and even oppostite strategies may be both useful
bearophile wrote:
> Lutger:
>
>> Adding random features to a language just because they look cool is a
>> terrible thing to do.
>
>>Isn't this a bit contradictory?<
>
> I don't see a contradiction. For example list comprehensions and unit
> testing module aren't random features, they are known
Lutger:
> Adding random features to a language just because they look cool is a
> terrible thing to do.
>Isn't this a bit contradictory?<
I don't see a contradiction. For example list comprehensions and unit testing
module aren't random features, they are known to be quite useful.
>list compr
On Mon, 27 Jul 2009 15:30:17 -0400, bearophile
wrote:
Steven Schveighoffer:
property
{
int x() {}
void x(int n) {}
bool empty() {}
}
An alternative:
property(x) {
... // or getter and/or setter
}
No, that is a different proposal. All I was saying is if property is an
Steven Schveighoffer:
> property
> {
> int x() {}
> void x(int n) {}
> bool empty() {}
> }
An alternative:
property(x) {
... // or getter and/or setter
}
Bye,
bearophile
Lutger wrote:
Andrei Alexandrescu wrote:
...
At the end of the day, a property is a notational convenience.
That sums up the discussion pretty nicely. Except for one thing: what do you
think of the ability of tools ( I include metaprogramming with this ) to
recognize properties as such?
Andrei Alexandrescu wrote:
...
> At the end of the day, a property is a notational convenience.
That sums up the discussion pretty nicely. Except for one thing: what do you
think of the ability of tools ( I include metaprogramming with this ) to
recognize properties as such?
bearophile wrote:
> Lutger:
>
>>It's interesting why unittest (and assert) are such big success. My idea
>>is that it's not in spite of, but because of their utter simplicity. I
>>speculate that if it would have been different, for example if you would
>>had to create a new file for a unittest,
On Mon, 27 Jul 2009 13:59:53 -0400, Andrei Alexandrescu
wrote:
Bill Baxter wrote:
On Mon, Jul 27, 2009 at 7:13 AM, Steven
Schveighoffer wrote:
On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright
wrote:
Ary Borenszweig wrote:
Maybe what scares Walter is a whole new syntax for properties.
Sergey Gromov wrote:
> The only thing copy-construction is useful for is implementing move
> semantics, think std::auto_ptr. Seems like everything else can be done
> in post-blit.
The "linked list" implementation of smart pointers also requires a copy
constructor. It's (arguably) not a very good
Bill Baxter wrote:
On Mon, Jul 27, 2009 at 7:13 AM, Steven
Schveighoffer wrote:
On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright
wrote:
Ary Borenszweig wrote:
Maybe what scares Walter is a whole new syntax for properties.
It doesn't scare me. It's trivial to add more syntax.
It's just tha
On Mon, 27 Jul 2009 13:23:42 -0400, Bill Baxter wrote:
On Mon, Jul 27, 2009 at 7:13 AM, Steven
Schveighoffer wrote:
On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright
wrote:
Ary Borenszweig wrote:
Maybe what scares Walter is a whole new syntax for properties.
It doesn't scare me. It's tr
On Mon, Jul 27, 2009 at 7:13 AM, Steven
Schveighoffer wrote:
> On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright
> wrote:
>
>> Ary Borenszweig wrote:
>>>
>>> Maybe what scares Walter is a whole new syntax for properties.
>>
>> It doesn't scare me. It's trivial to add more syntax.
>>
>> It's just t
Steven Schveighoffer Wrote:
> On Mon, 27 Jul 2009 12:16:59 -0400, Andrei Alexandrescu
> wrote:
>
> > Steven Schveighoffer wrote:
> >> On Mon, 27 Jul 2009 10:54:00 -0400, Andrei Alexandrescu
> >> wrote:
> >>
> >>>
> That's why properties are not
> functions.
> >>>
> >>> This post h
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
I think the only way you and Walter can understand what a property
is and what it is used for is to use for some time a language that
impleme
On Mon, 27 Jul 2009 12:16:59 -0400, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Mon, 27 Jul 2009 10:54:00 -0400, Andrei Alexandrescu
wrote:
That's why properties are not
functions.
This post had a negative effect on me: I now think properties are
functions even more
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
I think the only way you and Walter can understand what a property
is and what it is used for is to use for some time a language that
implements them. For example C#. Th
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
I think the only way you and Walter can understand what a property
is and what it is used for is to use for some time a language that
implements them. For example C#. Then you'll say "that's ni
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
I think the only way you and Walter can understand what a property is
and what it is used for is to use for some time a language that
implements them. For example C#. Then you'll say "that's nice" and
would want to imple
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
I think the only way you and Walter can understand what a property is
and what it is used for is to use for some time a language that
implements them. For example C#. Then you'll say "that's nice" and
would want to implement it in D.
I totall
Steven Schveighoffer wrote:
On Mon, 27 Jul 2009 10:54:00 -0400, Andrei Alexandrescu
wrote:
That's why properties are not
functions.
This post had a negative effect on me: I now think properties are
functions even more than before.
Let me bring you back to the issue at hand:
writefln =
On Mon, 27 Jul 2009 10:54:00 -0400, Andrei Alexandrescu
wrote:
That's why properties are not
functions.
This post had a negative effect on me: I now think properties are
functions even more than before.
Let me bring you back to the issue at hand:
writefln = "hi";
:)
properties are
Ary Borenszweig wrote:
I think the only way you and Walter can understand what a property is
and what it is used for is to use for some time a language that
implements them. For example C#. Then you'll say "that's nice" and would
want to implement it in D.
I totally agree that "that's nice".
Andrei Alexandrescu wrote:
Kagamin wrote:
Walter Bright Wrote:
Properties. Your syntactic sugar:
int i = c.p; // int i = c.p() p = i // c.p(i)
They can't do these things:
* No control over their use by class designer: ANY member
function with one or zero parameters may be called using
'prop
bearophile wrote:
> Michiel Helvensteijn:
>
>>I don't know a compelling use-case either. But that doesn't mean there
>>isn't any. Nor are there any real dangers. Arbitrarily restricting the
>>possibilities of D doesn't seem like the right way to go.<
>
> Adding random features to a language just
Kagamin wrote:
Walter Bright Wrote:
Properties. Your syntactic sugar:
int i = c.p; // int i = c.p() p = i // c.p(i)
They can't do these things:
* No control over their use by class designer: ANY member
function with one or zero parameters may be called using
'property syntax'. This is not a
Walter Bright Wrote:
> > Properties. Your syntactic sugar:
> >
> > int i = c.p; // int i = c.p()
> > p = i // c.p(i)
> >
> > They can't do these things:
> >
> > * No control over their use by class designer: ANY member function with one
> > or zero parameters may be called using 'property synta
On Fri, 24 Jul 2009 17:40:37 -0400, Walter Bright
wrote:
Ary Borenszweig wrote:
Maybe what scares Walter is a whole new syntax for properties.
It doesn't scare me. It's trivial to add more syntax.
It's just that D is complex enough - there needs to be some very good
reasons for adding m
Walter Bright:
>Lazy parameter evaluation may turn out to be a bad idea, it doesn't seem to
>have found its "groove" anywhere.<
Lazy parameters allow me to implement a poor's man list comprehensions.
Once list comprehensions are built-in, I don't need lazy parameters much
anymore.
Why list com
Sun, 26 Jul 2009 21:23:35 -0500, Andrei Alexandrescu wrote:
> Sergey Gromov wrote:
>> Fri, 24 Jul 2009 16:58:50 -0500, Andrei Alexandrescu wrote:
>>
>> deterministic destructors, arbitrary copy constructors, and optional
>> lack of default constructor.
> Struct have that except for d
Sergey Gromov wrote:
Fri, 24 Jul 2009 16:58:50 -0500, Andrei Alexandrescu wrote:
deterministic destructors, arbitrary copy constructors, and optional
lack of default constructor.
Struct have that except for default constructor. In D, currently default
constructors cannot execute code. This is
Fri, 24 Jul 2009 16:58:50 -0500, Andrei Alexandrescu wrote:
deterministic destructors, arbitrary copy constructors, and optional
lack of default constructor.
>>> Struct have that except for default constructor. In D, currently default
>>> constructors cannot execute code. This is a limi
On Fri, 24 Jul 2009 22:58:33 -0400, Andrei Alexandrescu
wrote:
Rainer Deyke wrote:
Ary Borenszweig wrote:
Maybe what scares Walter is a whole new syntax for properties. If at
least you could say which functions are properties and which are not,
that would be a small change and it'll make it
On Fri, 24 Jul 2009 21:36:53 -0400, Daniel Keep
wrote:
There's also the argument for debuggers being able to automatically
display properties; I think this one is fairly borderline since if I was
writing a debugger, it would only *automatically* display the result of
pure functions, property
Rainer Deyke, el 25 de julio a las 13:20 me escribiste:
> Leandro Lucarella wrote:
> > It has, providing tuples without that generally doesn't need language
> > support, like D or C++ tuples. When you have multiple assignment, you can
> > fully use the power of tuples, if not, it's just syntax suga
On Sat, Jul 25, 2009 at 02:15:00PM -0300, Leandro Lucarella wrote:
> if not, it's just syntax sugar for structs,
> or some kind of limited list.
Interestingly, I've been looking at tuples almost entirely as "anonymous
structs", if you will. Perhaps this is another bias preventing me from seeing
th
On Sat, Jul 25, 2009 at 01:20:33PM -0600, Rainer Deyke wrote:
> >From the Boost.Tuple documentation:
>
> int i; char c; double d;
> tie(i, c, d) = make_tuple(1,'a', 5.5);
> std::cout << i << " " << c << " " << d;
>
> So C++ tuples *do* support multiple assignment, even without language
> s
Leandro Lucarella wrote:
> It has, providing tuples without that generally doesn't need language
> support, like D or C++ tuples. When you have multiple assignment, you can
> fully use the power of tuples, if not, it's just syntax sugar for structs,
> or some kind of limited list.
>From the Boost.
Walter Bright Wrote:
> Steven Schveighoffer wrote:
> > On Fri, 24 Jul 2009 14:10:59 -0400, Walter Bright
> > wrote:
> >> That's my problem with properties as a distinct syntax - they don't
> >> have distinct uses or behaviors.
> >
> > If you delineate what can be called how, then you elminate
Jesse Phillips, el 25 de julio a las 03:38 me escribiste:
> > But you should support multple assignment, for example. If you don't,
> > you don't have real tuple support, just a toy tuple emulation.
>
> Tuples have nothing to do with multiple assignment, it is just something
> languages tend to p
Andrei Alexandrescu wrote:
> Rainer Deyke wrote:
>> Ary Borenszweig wrote:
>>> Maybe what scares Walter is a whole new syntax for properties. If at
>>> least you could say which functions are properties and which are not,
>>> that would be a small change and it'll make it possible for other
>>> th
"Nick Sabalausky" wrote in message
news:h4eg2c$sn...@digitalmars.com...
> "Walter Bright" wrote in message
> news:h4d9jt$1hq...@digitalmars.com...
>> Steven Schveighoffer wrote:
>>> On Fri, 24 Jul 2009 14:10:59 -0400, Walter Bright
>>> wrote:
That's my problem with properties as a distin
"Walter Bright" wrote in message
news:h4d9jt$1hq...@digitalmars.com...
> Steven Schveighoffer wrote:
>> On Fri, 24 Jul 2009 14:10:59 -0400, Walter Bright
>> wrote:
>>> That's my problem with properties as a distinct syntax - they don't have
>>> distinct uses or behaviors.
>>
>> If you delineat
Michel Fortin wrote:
> On 2009-07-24 22:58:33 -0400, Andrei Alexandrescu
> said:
>
>> This is pretty clean, and in keep with the opXxx approach. Actually how
>> about defining property foo by defining opGet_foo and opSet_foo.
>
> The problem with this is that it's ugly. What about this
>
> int
Walter Bright wrote:
Rainer Deyke wrote:
I don't care about your coding standards. I know how to use C++. I
have my own rules about how to use it safely and effectively, rules that
I have spent a lifetime refining.
I've been writing software for 35 years. I'm still learning new ways of
doin
Rainer Deyke wrote:
I don't care about your coding standards. I know how to use C++. I
have my own rules about how to use it safely and effectively, rules that
I have spent a lifetime refining.
I've been writing software for 35 years. I'm still learning new ways of
doing things and discardin
On Fri, 24 Jul 2009 12:30:23 -0300, Leandro Lucarella wrote:
> Adam D. Ruppe, el 23 de julio a las 22:56 me escribiste:
>> Tuple!(int, int) getPoint() { return tuple(5,2); }
>>
>> That works, but then you have to address the return value as:
>>
>> auto p = getPoint();
>> p.field[0] == 5
>> p.fi
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
Well I use it sometimes too, but it's so fraught with peril that
virtually all coding standards I've ever seen, all books and magazine
articles on the topic, all pundits, say one thing: don't. Better use
composition.
My take on composition vs inhe
On 2009-07-24 22:58:33 -0400, Andrei Alexandrescu
said:
This is pretty clean, and in keep with the opXxx approach. Actually how
about defining property foo by defining opGet_foo and opSet_foo.
The problem with this is that it's ugly. What about this
int foo.opGet();// getter
Andrei Alexandrescu wrote:
> Well I use it sometimes too, but it's so fraught with peril that
> virtually all coding standards I've ever seen, all books and magazine
> articles on the topic, all pundits, say one thing: don't. Better use
> composition.
My take on composition vs inheritance is very
On 2009-07-24 17:40:37 -0400, Walter Bright said:
It's just that D is complex enough - there needs to be some very good
reasons for adding more syntax that has apparently zero semantic
information that would be different from the usual function syntax.
You know. I agree with you on that poin
Rainer Deyke wrote:
Ary Borenszweig wrote:
Maybe what scares Walter is a whole new syntax for properties. If at
least you could say which functions are properties and which are not,
that would be a small change and it'll make it possible for other
things. Something like:
int property foo(); //
Andrei Alexandrescu wrote:
> Rainer Deyke wrote:
>> Composition instead of inheritance? Doesn't work if I need virtual
>> functions.
>
> This is going in circles. You started from "implementation inheritance
> of value types, even without actual polymorphism".
Yes, but implementation inheritance
Leandro Lucarella wrote:
> Yes, that's true, but this is a common problem. Think of operator
> overloading... Even in Python that could mean *anything* (__getattr__).
I want a programming language that enables me to write good code, not
one that prevents me from writing bad code. Abusing operator
Ary Borenszweig wrote:
> Maybe what scares Walter is a whole new syntax for properties. If at
> least you could say which functions are properties and which are not,
> that would be a small change and it'll make it possible for other
> things. Something like:
>
> int property foo(); // getter
> in
Walter Bright wrote:
> Michiel Helvensteijn wrote:
>> That's just a few reasons right there. D's properties lack elegance
>> and they
>> lack potential.
> Let's start with:
>
> 1. What is a property?
A piece of state referred to by some name; state which is usually part
of some object. Semantic
On Fri, Jul 24, 2009 at 6:44 PM, Andrei
Alexandrescu wrote:
> Bill Baxter wrote:
>>
>> On Fri, Jul 24, 2009 at 2:19 PM, Andrei
>> Alexandrescu wrote:
>>>
>>> Jarrett Billingsley wrote:
On Thu, Jul 23, 2009 at 5:56 PM, Michiel
Helvensteijn wrote:
>
> Eldar Insafutdinov wrote:
Bill Baxter wrote:
On Fri, Jul 24, 2009 at 2:19 PM, Andrei
Alexandrescu wrote:
Jarrett Billingsley wrote:
On Thu, Jul 23, 2009 at 5:56 PM, Michiel
Helvensteijn wrote:
Eldar Insafutdinov wrote:
from your post:
property int length {
get() { return this.len; }
set(newLen) { this.len = ne
Walter Bright wrote:
>> That's just a few reasons right there. D's properties lack elegance and
>> they lack potential.
>
> Let's start with:
> 1. What is a property?
> 2. How is that different from, say, a pure function?
I agree with Bill's reply to this one.
Again it appears you're avoiding t
Walter Bright wrote:
> Michiel Helvensteijn wrote:
>> That's just a few reasons right there. D's properties lack elegance and
>> they lack potential.
>
> Let's start with:
>
> 1. What is a property?
A property contains information describing some object, which may or may not
be mutable.
> 2
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
Rainer Deyke wrote:
1. C++'s object model, complete with polymorphic value types,
What designs make good use of polymorphic value types?
In a way, that's a loaded question, since C++ classes don't stay
polymorphic when passed around by value. A
On Fri, Jul 24, 2009 at 2:44 PM, Walter
Bright wrote:
> Michiel Helvensteijn wrote:
>>
>> That's just a few reasons right there. D's properties lack elegance and
>> they
>> lack potential.
>
> Let's start with:
>
> 1. What is a property?
"""
Properties are members that provide a flexible mechanism
Steven Schveighoffer wrote:
It's a good strategy for someone who's word is almost law when it comes
to D. You have to be careful what you say, flip-flopping around only
leads to knee-jerk feature additions, more bikeshed discussions, and
more people clammoring for feature additions (hey, you a
Michiel Helvensteijn wrote:
That's just a few reasons right there. D's properties lack elegance and they
lack potential.
Let's start with:
1. What is a property?
2. How is that different from, say, a pure function?
Ary Borenszweig wrote:
Maybe what scares Walter is a whole new syntax for properties.
It doesn't scare me. It's trivial to add more syntax.
It's just that D is complex enough - there needs to be some very good
reasons for adding more syntax that has apparently zero semantic
information that
Steven Schveighoffer wrote:
On Fri, 24 Jul 2009 14:10:59 -0400, Walter Bright
wrote:
That's my problem with properties as a distinct syntax - they don't
have distinct uses or behaviors.
If you delineate what can be called how, then you elminate syntax
ambiguities from occurring, and eliminat
On Fri, Jul 24, 2009 at 2:19 PM, Andrei
Alexandrescu wrote:
> Jarrett Billingsley wrote:
>>
>> On Thu, Jul 23, 2009 at 5:56 PM, Michiel
>> Helvensteijn wrote:
>>>
>>> Eldar Insafutdinov wrote:
>>>
from your post:
property int length {
get() { return this.len; }
set(ne
On Fri, Jul 24, 2009 at 5:19 PM, Andrei
Alexandrescu wrote:
>> obj.prop op= value;
>>
>> Simply becomes:
>>
>> obj.prop.set(obj.prop.get op value);
>
> I think this would be inefficient in many cases.
Um, what do you have to write now? "obj.prop = obj.prop op value".
All I'm suggesting is that t
1 - 100 of 253 matches
Mail list logo
