On Sun, 10 Feb 2013 11:52:47 -0500, Robert wrote:
On Sun, 2013-02-10 at 10:43 -0500, Steven Schveighoffer wrote:
On Sun, 10 Feb 2013 07:09:52 -0500, Robert wrote:
> Ok, at the very first I have to make clear that my DIP is about
changing
> the actual specification, not trying to make the i
On Sun, 2013-02-10 at 10:43 -0500, Steven Schveighoffer wrote:
> On Sun, 10 Feb 2013 07:09:52 -0500, Robert wrote:
>
> > Ok, at the very first I have to make clear that my DIP is about changing
> > the actual specification, not trying to make the implementation to match
> > the specification, bec
On Sun, 10 Feb 2013 07:09:52 -0500, Robert wrote:
Ok, at the very first I have to make clear that my DIP is about changing
the actual specification, not trying to make the implementation to match
the specification, because in my view of things, the specification is
the problem.
Properties in m
> How?! I mean yeah, you can return a pointer to a field, that is correct.
> But apart from that, which might get forbidden too for properties (I
> have to think about it first), what do you mean?
> >
I mean of course you can. Always. There are many ways:
- alias this
- some oth
> >
> > Read the DIP?
>
> Stop trolling.
Agreed, sorry. But by reading some arguments that are posted over and
over again, I just get the feeling that people don't even read it, which
is kinda frustrating, as it was a lot of work.
>
> > It is about encapsulation
>
> Perfectly possible without D
On 02/10/2013 01:53 PM, Robert wrote:
On Sun, 2013-02-10 at 13:40 +0100, Timon Gehr wrote:
Why does this justify a keyword? I think Walter's initial proposal of
getting rid of @property has more merit than this.
Read the DIP?
Stop trolling.
It is about encapsulation
Perfectly possible wi
> The reason why we should not, is that having such a cool
> straight forward feature for providing proper no-boilerplate
> encapsulation seems valuable in an OOP enabled language.
>
Provided we actually give properties this meaning in D, which is
currently not the case.
On Sun, 2013-02-10 at 13:40 +0100, Timon Gehr wrote:
> Why does this justify a keyword? I think Walter's initial proposal of
> getting rid of @property has more merit than this.
Read the DIP? It is about encapsulation and making set functions
callable with = in order to be compatible with ref ret
On 02/10/2013 01:09 PM, Robert wrote:
...
In my DIP a property is a function and they behave the same, except that
prop=5; calls prop(5); if prop is a property.
...
Why does this justify a keyword? I think Walter's initial proposal of
getting rid of @property has more merit than this.
Ok, at the very first I have to make clear that my DIP is about changing
the actual specification, not trying to make the implementation to match
the specification, because in my view of things, the specification is
the problem.
Properties in my proposal are no longer about optional parentheses or
On Fri, 08 Feb 2013 16:45:58 -0500, Robert wrote:
First of all, thanks for this very insight full discussion. I start to
understand the other side. :-)
You are welcome! I also am learning things and shaping my opinions based
on these discussions.
On Fri, 2013-02-08 at 15:13 -0500, Steve
On Friday, 8 February 2013 at 21:02:10 UTC, Andrei Alexandrescu
wrote:
On 2/8/13 2:05 PM, Robert wrote:
Look at the section "No module-level properties". Why not?!
That's a
perfectly valid use of properties. The proposal disallows
module-level
properties, but instead allows:
42.fun = 4
On Fri, 2013-02-08 at 22:15 +0100, FG wrote:
> Or should void front(T val) remain a
> @property, while ref T front() becomes a plain function?
Exactly.
First of all, thanks for this very insight full discussion. I start to
understand the other side. :-)
On Fri, 2013-02-08 at 15:13 -0500, Steven Schveighoffer wrote:
> On Fri, 08 Feb 2013 14:05:40 -0500, Robert wrote:
>
> > On Fri, 2013-02-08 at 12:52 -0500, Steven Schveighoffer wrote:
> >>
> >> T
On 2013-02-08 21:13, Steven Schveighoffer wrote:
I can't find anything about that front has to be a property here:
http://dlang.org/phobos/std_range.html#isInputRange
all it states that you can get the current element by issuing:
r.front
which would still be possible with the optional parent
On 2/8/13 2:05 PM, Robert wrote:
Look at the section "No module-level properties". Why not?! That's a
perfectly valid use of properties. The proposal disallows module-level
properties, but instead allows:
42.fun = 43;
which reads like: assign 43 to the fun property of 42. We get this
real
On Fri, 08 Feb 2013 14:05:40 -0500, Robert wrote:
On Fri, 2013-02-08 at 12:52 -0500, Steven Schveighoffer wrote:
Then it doesn't conform to the range API, where front is a property.
I can't find anything about that front has to be a property here:
http://dlang.org/phobos/std_range.html#isInp
On Fri, 2013-02-08 at 12:52 -0500, Steven Schveighoffer wrote:
>
> Then it doesn't conform to the range API, where front is a property.
I can't find anything about that front has to be a property here:
http://dlang.org/phobos/std_range.html#isInputRange
all it states that you can get the current
On Fri, 08 Feb 2013 10:28:14 -0500, eskimo wrote:
Ok, forget backwards compatibility for a moment, it was just an
additional goody.
On Thu, 2013-02-07 at 19:38 -0500, Steven Schveighoffer wrote:
Not with @property
That's the point, it would no longer be a property but a simple function
ret
Ok, forget backwards compatibility for a moment, it was just an
additional goody.
On Thu, 2013-02-07 at 19:38 -0500, Steven Schveighoffer wrote:
> Not with @property
>
>
That's the point, it would no longer be a property but a simple function
returning ref.
front for arrays would not be a prope
On Thu, 07 Feb 2013 16:28:42 -0500, Robert wrote:
On Thu, 2013-02-07 at 16:08 -0500, Steven Schveighoffer wrote:
int delegate()[] arr;
arr.front();
That's part of the mess we are trying to clean up here? As of DIP 23,
you would have to do arr.front()() in order to actually call the
delegate
On 02/07/2013 10:28 PM, Robert wrote:
On Thu, 2013-02-07 at 16:08 -0500, Steven Schveighoffer wrote:
int delegate()[] arr;
arr.front();
That's part of the mess we are trying to clean up here?
Of course.
As of DIP 23, you would have to do arr.front()() in order to actually call the
delegat
On 2/7/13 4:07 PM, Steven Schveighoffer wrote:
Most certainly, we should not outlaw taking the address of ref
parameters because it's "hard" to solve the problem of getting property
delegates (but only as long as people insist that adding to __traits is
taboo). That was MY point. Your "solving" a
On Thu, 2013-02-07 at 16:08 -0500, Steven Schveighoffer wrote:
> int delegate()[] arr;
>
> arr.front();
That's part of the mess we are trying to clean up here? As of DIP 23,
you would have to do arr.front()() in order to actually call the
delegate.
The current behaviour is also that you have to
On Thu, 07 Feb 2013 15:14:22 -0500, Andrei Alexandrescu
wrote:
On 2/7/13 2:13 PM, Steven Schveighoffer wrote:
On Thu, 07 Feb 2013 13:05:50 -0500, Robert wrote:
Properties provide a means of access control to fields. (Range checks,
only readable, only writable, triggering a signal on chang
On Thu, 07 Feb 2013 15:57:56 -0500, Robert wrote:
Just to be clear here, with DIP23 in place, the syntax at the caller
side for:
@property ref T front(T[] arr) { return arr[0];}
would not change if you remove the @property. So little code breakage
here and the code that breaks is easily fixed
Just to be clear here, with DIP23 in place, the syntax at the caller
side for:
@property ref T front(T[] arr) { return arr[0];}
would not change if you remove the @property. So little code breakage
here and the code that breaks is easily fixed by removing @property.
It depends on how we are going to define properties and with all the
arguments in the discussions it seems to me that the only sane way to
design properties is as simple front ends for private fields (which is
my understanding of properties anyway).
But with optional parantheses the @property wou
On 2/7/13 2:13 PM, Steven Schveighoffer wrote:
On Thu, 07 Feb 2013 13:05:50 -0500, Robert wrote:
Properties provide a means of access control to fields. (Range checks,
only readable, only writable, triggering a signal on change, ...)
So as posted a few times, taking the address of the ref ret
Good point, but I think that this is pretty much a corner case where it
occasionally might be useful, but it does not rectify the consequences:
The moment you are allowed to take the address, you are stuck with the
ref returning accessor and can not change it later to a get/set pair.
An easy solu
On Thu, 07 Feb 2013 13:05:50 -0500, Robert wrote:
Properties provide a means of access control to fields. (Range checks,
only readable, only writable, triggering a signal on change, ...)
So as posted a few times, taking the address of the ref return value of
a property is of no value at all. I
On 2013-02-07 19:05, Robert wrote:
taking the address of the ref return value of a property is of no
value at all. If you want someone to be able to take the address
of a field, you should make it simply public (without @property),
because the @property accessor methods won't gain you anything in
Properties provide a means of access control to fields. (Range checks,
only readable, only writable, triggering a signal on change, ...)
So as posted a few times, taking the address of the ref return value of
a property is of no value at all. If you want someone to be able to take
the address of a
33 matches
Mail list logo
