View mode: basic / threaded / horizontal-split · Log in · Help
November 20, 2012
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 05:31:09 UTC, deadalnix wrote:
> This make it impossible to only define a getter only when one 
> want to return by reference.

If there isn't a setter, you don't change things.

If setter is present:
foo = foo + 1; // becomes: foo(foo() + 1);

If setter is not present:
foo = foo + 1; // becomes: foo() = foo() + 1;


If foo returns an rvalue, this is a natural error. If it returns 
ref, it works fine.
November 20, 2012
Re: @property needed or not needed?
On Tue, 20 Nov 2012 13:26:15 -0000, Adam D. Ruppe  
<destructionator@gmail.com> wrote:

> On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote:
>> Should this be allowed for functions that isn't marked with @property:
>>
>> foo = 3;
>
> Yes. We should *only* be changing the way @property is implemented.  
> (Namely, actually implementing it!)
>
> Don't want to break existing code. The new changes must be opt in.

Usually I'd agree but this is a case of a wart we should just remove IMO.   
The fix for breaking cases is simple, add @property.

> If there's both an @property setter and a regular function, the property  
> should be used here.

Agreed.  But it's waay clearer whats going on if @property is required to  
call functions using this syntax.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
November 20, 2012
Re: @property needed or not needed?
On Tue, 20 Nov 2012 13:20:10 -0000, monarch_dodra <monarchdodra@gmail.com>  
wrote:

> On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote:
>> Should this be allowed for functions that isn't marked with @property:
>>
>> foo = 3;
>
> Hell no!

+1 I think this "feature" should just be removed, and @property  
implemented fully/correctly.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
November 20, 2012
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 13:50:10 UTC, Regan Heath wrote:
> Usually I'd agree but this is a case of a wart we should just 
> remove IMO.  The fix for breaking cases is simple, add 
> @property.

meh, I sometimes use it, but if overloading on @property works, 
that's easy enough to allow both ways.

I use it in some big chaining things:

Element.make("div").className("foo").value = "bar";

vs

auto element = Element.make("div");
element.className = "foo";
element.value = "bar";


Using one or the other depending on if I have a variable name 
there anyway. This would be arguably *better* with separation, 
but I don't have the level of hatred for one function used both 
ways (on setter nor getter) the way a lot of people do.
November 20, 2012
Re: @property needed or not needed?
BTW I've been pasting some of my posts into the wiki thing

http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP21#section4


Kinda sloppy to just paste, but this way everything on my mind is 
in one place so we don't have to reread the thread to get it 
together.

Of course, being a wiki, feel free to do the same with anything 
you want to note.
November 20, 2012
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 14:13:51 UTC, Adam D. Ruppe wrote:
> On Tuesday, 20 November 2012 at 13:50:10 UTC, Regan Heath wrote:
>> Usually I'd agree but this is a case of a wart we should just 
>> remove IMO.  The fix for breaking cases is simple, add 
>> @property.
>
> meh, I sometimes use it, but if overloading on @property works, 
> that's easy enough to allow both ways.
>
> I use it in some big chaining things:
>
> Element.make("div").className("foo").value = "bar";
>
> vs
>
> auto element = Element.make("div");
> element.className = "foo";
> element.value = "bar";

That's a good point. If the property is a "setter", then both 
"value = bla" and "value(bla)" is legal.

If the property is a getter, then only "=" works. But I think it 
would be fine if "value(bla)" were tanslated to "value = bla" in 
that case.

However, if you allow "foo = rhs" => "foo(rhs)" on a non-propety, 
then code like this becomes legal:
writeln = 5;
And that's bullshit.
November 20, 2012
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 13:26:17 UTC, Adam D. Ruppe wrote:
> On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg 
> wrote:
>> Should this be allowed for functions that isn't marked with 
>> @property:
>>
>> foo = 3;
>
> Yes. We should *only* be changing the way @property is 
> implemented. (Namely, actually implementing it!)
>
> Don't want to break existing code. The new changes must be opt 
> in.

Here's another way to test if the idea is sound, by asking a few 
questions:

For some time, we've had the unrestricted ability to drop empty 
"()" and perform assignments to any function with appropriate 
sig. Has there been a chorus of complaints about having it? Any 
flood of problems caused by it? More importantly, how many of us 
are now making good use out of it without even a seconds thought? 
How many of us would really miss it if taken out?

I still think there's a lot more to the picture, but I cannot yet 
pin it down well enough to say what it is.

I'll try and share my thoughts, so that maybe someone more 
knowledgeable than me can figure it out.

What is really bugging me, is that I know there's something more 
generalized going on here that we may have an opportunity to take 
advantage of, before things get cast in "unbreakable" stone, so 
to speak.

I've been asking myself some questions, off the wall stuff, not 
necessarily possible for D due to practical limitations, but 
perhaps possible for E:

1) Why must a variable operate as it does and why must a function 
operate as it does? Are the two "things" really all that much 
different? I can successfully imagine that a variable is a 
function wrapper around a data store.

2) We're allowing only some functions to operate like variables, 
and this is because not all functions are allowed to operate in 
this way due to their parameter signature. Specifically, if the 
function has more than one parameter, it cannot be used as if it 
were a variable.

Example:

// We can do this

void Foo( int ){ ... };
int Foo(){ ... };
Foo = 5;
int Y = Foo;

// so why not something like this?

void Foo( int, string, float ){ ... };
( int, string, float )Foo(){ ... };

Foo = { 1, "test", 3.456 };
{ someint, somestring, sonefloat } = Foo;

Why must we be limited to a single return and a single assignment 
value?
(I recall this topic was brought up before, and I know we can use 
struct to emulate a similar effect)

3) If some functions can operate like variables, then why must no 
variable be able to operate like some functions?

This is not allowed in D:

int x, y;
x(1);
y = x();
y(x());

Why must this be so?

4) Which syntax or constructs are easier to understand, and which 
are not, given the context they are used in? If we had choice, 
will the context prefer one syntax over another in terms of 
clarity? If we don't have choice, then the context may enforce 
poor clarity in some cases.

5) We really enjoy the power we get from generic templates, yet 
the generic abilities of templates may possibly be lessened 
considerably because of the incompatibility between variables and 
functions, and I would also say classes and structs, although 
with UFCS the situation has improved (which may be why we like 
having them so much).

6) What advantage do we get by making variables and functions 
incompatible with each other (in terms with how they are 
manipulated or operated on), and what advantages could we get if 
we made them fully compatible (or at least more compatible).

Hopefully some of these questions will provide food for some 
thought on the @property matter.

--rt
November 20, 2012
Re: @property needed or not needed?
Just a quick thought... it's not like a = 10 has no way to 
trigger a function anyway.

opAssign does it. Is that evil? This discussion kinda reminds me 
of some of the C++ arguments over operator overloading. They 
argue overloaded operators are evil because they don't look like 
function calls... but I think most of us agree that is generally 
useful.

D's properties of course aren't exactly the same but I think 
there's some similarities there that matter.
November 20, 2012
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 18:06:22 UTC, Rob T wrote:
> Here's another way to test if the idea is sound, by asking a 
> few questions:

After thinking about it a bit more, I think there may be two 
conflicting notions:

a) The use of optional parenthesis.
b) The @property switch, which allows a function to emulate an 
attribute, namelly, allow writting "bla = a.foo;" or "a.foo = 
5;", when "foo" isn't actually an attribute of a.

I *could* see parenthesis being optional, but I'll never accept 
"a.foo = 5" calling "a.foo(5)" if "foo" isn't attribute qualified.
November 20, 2012
Re: @property needed or not needed?
On Tuesday, November 20, 2012 19:48:01 monarch_dodra wrote:
> On Tuesday, 20 November 2012 at 18:06:22 UTC, Rob T wrote:
> > Here's another way to test if the idea is sound, by asking a
> 
> > few questions:
> After thinking about it a bit more, I think there may be two
> conflicting notions:
> 
> a) The use of optional parenthesis.
> b) The @property switch, which allows a function to emulate an
> attribute, namelly, allow writting "bla = a.foo;" or "a.foo =
> 5;", when "foo" isn't actually an attribute of a.

Yes, you basically have folks who want to have strictly defined properties 
which emulate variables (similar to what C# has), and you have folks who 
simply want to leave off parens (especially when they're using UFCS and already 
forced to provide a template argument - e.g. with map or filter or whatnot). On 
some level, they can coexist, and on some level, they're conflicting notions.

Given the fact that this subject is extremely devisive, I suspect that the 
best that we can hope for at this point is for lax property enforcement - that 
is that it's enforced that @property functions are used as properties but 
there is no enforcement that non-@property functions be called with parens. We 
might be able to further restrict them so that they can't be used with the 
setter syntax (making it so that they must be @property for that to work), but 
with UFCS and the use of templated functions taking predicates, dropping 
parens is way too popular to disallow it, much as I personally hate the idea.

- Jonathan M Davis
2 3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home