January 31, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to q66 | 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 |
January 31, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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/ |
January 31, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Michel Fortin | 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 |
January 31, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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 |
January 31, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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 |
January 31, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | 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!
|
January 31, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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 |
January 31, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 1/31/13 12:08 PM, Andrei Alexandrescu wrote:
> I'm that team!
s/that/on that/
|
January 31, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Michel Fortin | 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. |
January 31, 2013 Re: Possible @property compromise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Zach the Mystic | 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." |
Copyright © 1999-2021 by the D Language Foundation