On Thu, 31 Jan 2013 09:57:12 -0500, q66 <quaker66@gmail.com> wrote:

> On Thursday, 31 January 2013 at 14:28:39 UTC, Steven Schveighoffer wrote:
>> As another option, what about changing my proposal so instead of setX, it's set_x, and then casing concerns are eliminated?  I think C++.net does that.
>>
>> -Steve
>
> No, that is not a solution either. Any of these setBlah or set_blah or whatever are ugly hacks.

I don't agree, the benefit of being able to refer to the property as a function and as a property separately is nice.  For instance, you can get a delegate for the property.

The other benefit is that the setBlah or set_blah functions are self-descriptive as properties.  You would be hard pressed to argue such a function doesn't set a value called blah.

> There should be explicit property syntax. By explicit, I mean explicit - at least like C#'s get/set stuff

I would be fine with that too, but with all due respect, the only person whose opinion matters is Walter.

If he is possibly interested in any of these proposals instead of @property, I think that's the one we should go for.

> (and I don't really like C# either).

Why don't we start with a language you DO like that has properties?  Or are you sour on all of them?

-Steve

On 2013-01-31 14:50:40 +0000, "Steven Schveighoffer" <schveiguy@yahoo.com> said:

> It actually is a bit depressing, we have to reset the clock back to late  2009 to start over with properties...

I haven't participated in the discussions about properties this time around because it's pretty obvious to me it's getting nowhere.

It seems to me that nothing can be done at this point in time if we want to avoid a breakage of almost all current D code. Well, we could make some compromises, but a compromise is going to complicate things while solving only some of the issues; few of us will be really satisfied with such a thing.

By the way I was a big proponent of properties with no semantic ambiguities back in 2009. I even proposed a getX/setX scheme, which I still like very much. I'd like to see real properties in D, but I don't think it's realistic at this point.

And you have to admit that the way D does properties today is both simple, clever, and appealing. It does have some error-prone liabilities when it comes to callable types and generic programming especially, but beside that I do like the design of the thing. It's a natural extension of UFCS, even though it predates UFCS. Perhaps we should just call it a day and live with the ambiguities. I don't like it, but I don't see any viable alternative.


-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

On Thu, 31 Jan 2013 10:40:18 -0500, Michel Fortin <michel.fortin@michelf.ca> wrote:

> On 2013-01-31 14:50:40 +0000, "Steven Schveighoffer" <schveiguy@yahoo.com> said:
>
>> It actually is a bit depressing, we have to reset the clock back to late  2009 to start over with properties...
>
> By the way I was a big proponent of properties with no semantic ambiguities back in 2009. I even proposed a getX/setX scheme, which I still like very much. I'd like to see real properties in D, but I don't think it's realistic at this point.

Yes, I saw your post when looking for my post about the C# style which I couldn't find.

> And you have to admit that the way D does properties today is both simple, clever, and appealing. It does have some error-prone liabilities when it comes to callable types and generic programming especially, but beside that I do like the design of the thing. It's a natural extension of UFCS, even though it predates UFCS. Perhaps we should just call it a day and live with the ambiguities. I don't like it, but I don't see any viable alternative.

I liked it when I first saw it.  Seems, as you say, clever and intuitive.

However, it left a bad taste in my mouth when I had a certain situation that I was forced to deal with.

In Tango, I developed a struct called TimeSpan, which was a span of time (we have Duration in std.datetime which is similar).

I created constructors for spans of time that were named after the units they used.  For example, if you wanted a 10 minute, 30 second timespan you could do:

auto ts = TimeSpan.minutes(10) + TimeSpan.seconds(30);

The idea was to avoid having to document such a line, the above looks obvious.

Now, I also had accessors for a given timespan to return the timespan in those units.  For example:

assert(ts.seconds == 10 * 60 + 30);

The problem arose when someone complained that the seconds "setter" wasn't working:

ts.seconds = 5;

assert(ts.seconds != 5);

Wait, what?  I never made seconds a settable property!

Turns out, this translates to:

ts.seconds(5);

and because you can call static methods from an instance (another thing I don't really like), it made the constructor act like a property!  A completely unintended consequence.

The only viable solution (this was D1), was to rename the functions so they couldn't be mistaken as properties.  So they all became "fromSeconds" e.g.  Yuck!

This is one of the reasons I was so excited about D2 getting full-fledged properties.  I had used C# and liked the way those properties worked.

But we never got what was promised, and now we basically have the same junk with some duct-taped garbage keyword that half works.  No wonder people don't like @property!

At this point, I think it would be a huge step backwards not to solve (or at least have a yet-to-be implemented solution for) the above problem.  I can live with getters simply being parentheses-less functions, that isn't so bad (though as an API designer, I'd like to have full control over that).  But using any function as a setter is crap, and will forever be a wart on D unless we fix it.  It will result in bizarre things like mystery setters that don't exist, especially with UFCS.

-Steve

On 2013-01-31 15:28, Steven Schveighoffer wrote:

> Now we're just name calling ;)  I tend to think that for the most
> successful company in the business to standardize on it is a pretty good
> testimony to it being well designed.  I certainly have grown fond of it,
> there are some really nice features in it.  But truly, xcode has played
> a large role in making the language seem good.

And that is thanks to Clang and LLVM. Xcode wouldn't be nearly as good on autocompletion, refactoring and static analysis to mention a few features.

Also it has started to catch up in later years, thinking of Objective-C 2. More recently blocks, some kind of operator overloading and more object literals.

-- 
/Jacob Carlborg

On 2013-01-31 15:56, Steven Schveighoffer wrote:

> From what I remember Andrei saying, they write their code in C++ and
> compile it to php, or something like that.

I'm pretty sure it's the opposite. PHP code compiles to C++.

"HipHop programmatically transforms your PHP source code into highly optimized C++ and then uses g++ to compile it."

http://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php--move-fast/

-- 
/Jacob Carlborg

On 01/31/2013 03:56 PM, Steven Schveighoffer wrote:
> ...See PHP, for
>> example - a *horrible* mess of a language, but it is being used at
>> Facebook.
>
>  From what I remember Andrei saying, they write their code in C++ and
> compile it to php, or something like that.
>...

Other way round!

On 1/31/13 11:36 AM, Jacob Carlborg wrote:
> On 2013-01-31 15:56, Steven Schveighoffer wrote:
>
>> From what I remember Andrei saying, they write their code in C++ and
>> compile it to php, or something like that.
>
> I'm pretty sure it's the opposite. PHP code compiles to C++.
>
> "HipHop programmatically transforms your PHP source code into highly
> optimized C++ and then uses g++ to compile it."
>
> http://developers.facebook.com/blog/post/2010/02/02/hiphop-for-php--move-fast/

We use JITting right now: https://www.facebook.com/note.php?note_id=10150415177928920

I'm that team!


Andrei

On 1/31/13 12:08 PM, Andrei Alexandrescu wrote:
> I'm that team!

s/that/on that/

On Thursday, 31 January 2013 at 15:40:19 UTC, Michel Fortin wrote:
> And you have to admit that the way D does properties today is both simple, clever, and appealing. It does have some error-prone liabilities when it comes to callable types and generic programming especially, but beside that I do like the design of the thing. It's a natural extension of UFCS, even though it predates UFCS. Perhaps we should just call it a day and live with the ambiguities. I don't like it, but I don't see any viable alternative.

I'm hoping that the community won't close the books on this issue without even *examining* my proposal, found here:

http://forum.dlang.org/thread/kdukid$stg$1@digitalmars.com?page=2#post-yqvrjszzlcpmmuyqyxdz:40forum.dlang.org

If you want the main points, just read all of the posts by Zach the Mystic. I've done my best to defend all criticisms. I simply feel obliged to point out to everyone who wants to shut this issue down that there is another proposal. You may accuse me of being ignorant, or too new to know what I'm saying, but at least try to read the proposal and how the arguments against it have been defended.

Or just shut me up by saying something about why it's just wrong or simply can't work.

On Thursday, 31 January 2013 at 19:13:03 UTC, Zach the Mystic wrote:

Here's the most concise quote which gives you the gist of the thing:

"Now classes are a different kettle of fish. I haven't thought
them out and I don't think I need to. They may work seamlessly
with my idea or be fraught with problems, I don't know."

"But there will never be a need for a new empty struct. The
operator new makes no sense. There's no data! Imagine an empty
struct as a list of functions under a namespace. That's all it
really is. Except it just so happens that this namespace has a
bunch of built-in functions which allow it to appear in normal
code as if it's a *type*. Want it to appear with parens, so it
looks like a function you're calling? Just define opCall inside
the struct. Want it to appear before an equals sign. Just define
opAssign. As an array? opIndex. A basic type such as an int?
opGet. There will never be any need to create an instance. You
only need one. At runtime, there is no evidence of a pointer at
all, just normal data being passed to normal functions."