Re: The XML module in Phobos
Michel Fortin wrote: On 2009-08-01 00:04:01 -0400, Benji Smith said: But XML documents aren't really lists. They're trees. Do ranges provide an abstraction for working with trees (other than the obvious flattening algorithms, like breadth-first or depth-first traversal)? Well, it depends at what level you look. An XML document you read is first a list of bytes, then a list of Unicode characters, then you convert those characters to a list of tokens -- the Tango pull-parser sees each tag and each attribute as a token, SAX define each tag (including attributes) as a token and calls it an event -- and from that list of token you can construct a tree. The tree isn't a list though, and a range is a unidimentional list of something. You need another interface to work with the tree. But then, from the tree, create a list in one way or another (flattening, or performing an XPath query for instance) and then you can have a range representing the list of subtrees for the query if you want. That's pretty good since with a range you can lazily iterate over the results. Oh sure. I agree that a range-based way of iterating over tokens is cool. And a range-based API for walking through the results of an XPath query would be great. But the real meat and potatoes of an XML API would need to be something more DOM-like, with a tree structure. The only reason I chimed in, in the first place, was Andrei's post saying that a replacement XML parser "ideally outputs ranges". I don't think that's right. Ideally, an XML parser outputs a tree structure. Though a range-based mechanism for traversing that tree would be nice too. --benji
Re: new DIP5: Properties 2
Benji Smith wrote:
Andrei Alexandrescu wrote:
Thanks for these great points. As an additional example, most ranges
define the method
bool empty() { ... }
whereas infinite ranges define the enum
enum bool empty = false;
It follows that if a range user wants to be compatible with finite and
infinite ranges, they always must use no "()". It would be nice if the
range's definition could enforce that.
Andrei
Huh. How does this reconcile with your previous posts, where you said
it'd probably be a bad idea for the API designer to mandate the function
calling style of the API consumer?
Is this the same issue, and you've changed your mind? Or do you see this
as a different issue?
I found the way he put it - avoiding gratuitous inconsistency between
fields and properties - a compelling perspective.
Andrei
Re: new DIP5: Properties 2
Bill Baxter wrote: On Fri, Jul 31, 2009 at 10:09 PM, Andrei Alexandrescu wrote: Benji Smith wrote: So the clusterfuck of unenforceable and useless conventions is already here. Here's my suggestions: if you think putting parentheses on a no-arg function is stupid, then it should be a syntax error for them to exist. That wouldn't be my first choice, but it'd be a thousand times better than the situation with optional parens. --benji I agree that it's not good to have two ways of doing the same thing. Now think of it for a second: a full-blown language feature has been proposed to not fix that, but reify it. D already has a *truckload* of such features. Aliases, typedefs, renamed imports, and overloaded operators all exists solely so that a programmer can pretend that one thing is another thing, so that an API designer can more precisely express the *intent* of the code, and with semantics that are enforced by the compiler. Compared with those other features, I don't see what's so different about the properties proposals. --benji
Re: DIP guidelines [was: DIP6: Attributes]
On Sat, Aug 1, 2009 at 11:27 PM, Ellery Newcomer wrote: > They aren't. Decorators are deep crazy magic. As I recall, > > @mydecorator > def myfunc(argsnjunk): > pass > > transforms all calls to myfunc to a call to a function you defined > somewhere named mydecorator, which takes a function and its arguments as > parameters and returns a function which is expected to call the function > with its arguments. Then the returned function gets called. Close, but not quite. What instead happens is that this gets transformed into something like: myfunc = mydecorator()(lambda(argsnjunk): pass) That is, mydecorator() returns a callable; that callable takes the function that you're defining as its argument, potentially modifies or transforms it, then returns either the same function or anything else, which is finally stored in myfunc. Calls to myfunc are not transformed at all; all that has happened is that the decorator has intercepted the function definition, and might have replaced the original function with a new one.
Re: new DIP5: Properties 2
Andrei Alexandrescu wrote:
Thanks for these great points. As an additional example, most ranges
define the method
bool empty() { ... }
whereas infinite ranges define the enum
enum bool empty = false;
It follows that if a range user wants to be compatible with finite and
infinite ranges, they always must use no "()". It would be nice if the
range's definition could enforce that.
Andrei
Huh. How does this reconcile with your previous posts, where you said
it'd probably be a bad idea for the API designer to mandate the function
calling style of the API consumer?
Is this the same issue, and you've changed your mind? Or do you see this
as a different issue?
--benji
Re: Omissible Parentheses...
On Sat, Aug 01, 2009 at 11:49:04PM -0400, Benji Smith wrote: > >http://igsoft.net/dpolls/poll/results.php?pollid=1 > >http://igsoft.net/dpolls/poll/results.php?pollid=2 > > > > > >Andrei > > If I'm not mistaken, each of those polls shows a two-to-one preference > for getting rid of omissable parentheses and introducing a dedicated > property syntax of some kind. They also prove that there are more than one person who are fairly happy with the current system. There might be a majority in favor of a change, but the prospects are much more iffy about there being enough votes to kill our filibuster! (I'm not sure if filibusters are common outside of American politics, so if you aren't familiar with the term, it is when someone in the US Senate debates a proposed bill non stop until the proposal just dies and nothing is changed. The filibuster can be stopped with 60 votes out of the 100 senators - something that can be a pain to get, and leads to a lot of compromise to keep the bill alive. In other words: see what happens on this newsgroup :P ) > > --benji -- Adam D. Ruppe http://arsdnet.net
Re: Omissible Parentheses...
Andrei Alexandrescu wrote: Denis Koroskin wrote: On Sat, 01 Aug 2009 21:04:43 +0400, Chad J wrote: Omissible Parentheses Could someone remind me why we don't remove these? So far I have - They save typing. - Removing them breaks backwards compatibility. - They allow some features of properties, but with a list of limitations and gotchas. This is not intended to be a deep discussion. I'm writing a piece on properties, so I'm gathering information. Andrei likes them. http://igsoft.net/dpolls/poll/results.php?pollid=1 http://igsoft.net/dpolls/poll/results.php?pollid=2 Andrei If I'm not mistaken, each of those polls shows a two-to-one preference for getting rid of omissable parentheses and introducing a dedicated property syntax of some kind. --benji
Re: new DIP5: Properties 2
On Sat, 01 Aug 2009 20:48:58 -0400, Andrei Alexandrescu
wrote:
Sergey Gromov wrote:
Fri, 31 Jul 2009 21:37:06 -0500, Andrei Alexandrescu wrote:
To clarify: if there was any extra checking by the compiler, any
guarantee that the feature would provide at all, I'd be glad to pay
the price of thinking more when putting together a design. But you
want to define a language feature that allows people to require "()"
or not as they please, and that's all. It's a frivolous detail to be
spending time on when designing an API. I simply don't believe that's
good language design.
That's not "all." To me it's mostly maintainability.
If there is a property 'foo' and you allow to set it both as 'foo = 5'
and 'foo(5)' then somebody *will* use the foo(5) form. Making it hard,
or even impossible for you, the maintainer, to switch from a property
back to a regular field for 'foo'.
If you allow to call function 'bar()' both with and without
parentheses,
and a project is maintained by more than one person, they *will* call it
differently making the source look inconsistent.
Dropping the 'omittable parentheses' thing happens to solve these, and
the delegate return problem, and helps to disambiguate words with
overloaded meanings.
Thanks for these great points. As an additional example, most ranges
define the method
bool empty() { ... }
whereas infinite ranges define the enum
enum bool empty = false;
It follows that if a range user wants to be compatible with finite and
infinite ranges, they always must use no "()". It would be nice if the
range's definition could enforce that.
Andrei
Great points?
Sorry, but all it takes is one person to subclass and overload foo, and
then it can never be turned back into a field. That is, if you're worrying
about maintainability.
As for source code consistency, I view no-(), () and not caring as part
whole code format/variable issue. I mean, code::block has 5 different
layout styles (+custom definitions). What about variable names, hmm?
e/empty/isEmpty/is_empty? I would think any project than can maintain code
consistency of those other issues, they can also manage ()/no-()/mixed.
Hmm... I just had a crazy thought, regarding Andrei's enum bool empty =
false; example. What if in addition to functions as fields (aka
properties) D allowed fields as functions? i.e.
c.foo(5); => c.foo = 5
when method foo doesn't exist.
Re: DIP guidelines [was: DIP6: Attributes]
Ary Borenszweig wrote: > Leandro Lucarella escribió: >> Ary Borenszweig, el 1 de agosto a las 16:29 me escribiste: >>> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 >> >> Please, try to post at least the abstract of the DIP with the link, so >> people can easily know what is it about =) >> >> And when writing a DIP, try to make the abstract a little more >> descriptive. From an abstract you should be able to tell what the DIP is >> about (in this case explain what an annotation is at least). A >> oneliner is >> not good enough, that's just a title, not an abstract. If it's too hard >> to explain, try to provide a link to somewhere else where the terms are >> described. >> >> The rationale can be a little more descriptive too. What are the >> advantages of removing keywords for example? Use NG posts links if you >> have some problems documented there, for example. >> >> Try not to explain your opinion in DIPs. They are not NG posts, they >> should provide facts and be as objective as possible. Even when that's >> pretty hard, saying "I prefer Java's one because ..." is excessively >> subjective. Avoid doing that. You can express the same by saying >> something >> like "Java syntax has the advantage of ..." for example. >> >> A section called "Other thoughts" is not very serious either. If you are >> not yet convinced about something in the DIP, post it in the announcement >> post in the NG so it can be discussed and added later to the DIP when the >> idea is in better shape. >> >> Please, don't take this personally, I just want DIPs to be high quality, >> otherwise they will never be taken seriously. =) >> >> I've added this information in a Recommendations subsection to the DIP1, >> see: >> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1#Recommendations >> >> >> I'll address the DIP itself in another post ;) > > Hola Leandro, > > I've updated the DIP page with your recommendations. I agree with all of > them. > > Please, can someone (pst, bearophile) check that what I found as > decorators in Pyhton are what we are calling annotations here? Thanks! They aren't. Decorators are deep crazy magic. As I recall, @mydecorator def myfunc(argsnjunk): pass transforms all calls to myfunc to a call to a function you defined somewhere named mydecorator, which takes a function and its arguments as parameters and returns a function which is expected to call the function with its arguments. Then the returned function gets called. Very nifty for a wide variety of things.
Re: DIP guidelines [was: DIP6: Attributes]
Leandro Lucarella escribió: Ary Borenszweig, el 1 de agosto a las 16:29 me escribiste: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Please, try to post at least the abstract of the DIP with the link, so people can easily know what is it about =) And when writing a DIP, try to make the abstract a little more descriptive. From an abstract you should be able to tell what the DIP is about (in this case explain what an annotation is at least). A oneliner is not good enough, that's just a title, not an abstract. If it's too hard to explain, try to provide a link to somewhere else where the terms are described. The rationale can be a little more descriptive too. What are the advantages of removing keywords for example? Use NG posts links if you have some problems documented there, for example. Try not to explain your opinion in DIPs. They are not NG posts, they should provide facts and be as objective as possible. Even when that's pretty hard, saying "I prefer Java's one because ..." is excessively subjective. Avoid doing that. You can express the same by saying something like "Java syntax has the advantage of ..." for example. A section called "Other thoughts" is not very serious either. If you are not yet convinced about something in the DIP, post it in the announcement post in the NG so it can be discussed and added later to the DIP when the idea is in better shape. Please, don't take this personally, I just want DIPs to be high quality, otherwise they will never be taken seriously. =) I've added this information in a Recommendations subsection to the DIP1, see: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1#Recommendations I'll address the DIP itself in another post ;) Hola Leandro, I've updated the DIP page with your recommendations. I agree with all of them. Please, can someone (pst, bearophile) check that what I found as decorators in Pyhton are what we are calling annotations here? Thanks!
Re: YAPP - D properties - voting
Chad J schrieb: aarti_pl wrote: Ary Borenszweig pisze: That's because we can't see who is voting and if anyone is cheating. Trivial cheating is rather not possible - there is only one voice per IP. BR Marcin Kuszczak (aarti_pl) Interesting. I can't tell because it seems like I can still submit after voting, but I don't want to test it for fear of double-voting. You can't vote with the same IP, but with another one. Anyway, the poll doesn't present enough options IMO.
Re: property / getProperty() / setProperty()
On 2009-08-01 17:38:46 -0400, Jarrett Billingsley
said:
On Sat, Aug 1, 2009 at 4:01 PM, Michel Fortin wrote:
3. There is no naming ambiguity.
A set/get prefix removes pretty much all ambiguity too.
I mean, the current syntax is "T transform()" and you can't know if
transform is a noun or a verb. With my prefix it's "T getTransform()" which
makes it pretty clear what it does. With yours it's "property T transform()"
and it's pretty clear too.
class X
{
int foo;
int getFoo() { return 5; }
int blah() { return foo; /* um.. which? */ }
}
Ok. There's two fronts on "ambiguity". You can have ambiguity in
meaning, that's what I was talking about. By writing
"setTransform()"/"getTransform()" you remove that ambiguity about
"transform" being either a noun (property) or a verb (action). Having a
keyword property does also removes that ambiguity. That's what I was
talking about.
Your example describe a syntaxic ambiguity when there's already a
symbol named with the property name. There is a few way to solve that
ambiguity:
1. Make it ambiguous (thus an error) to invoke foo at all.
2. Make foo, the variable, shadow the property.
3. Make the property shadow the variable.
Number 3 is a bad idea because you have absolutely no way to access the
field, even from inside the getter and setter. I'm not sure 2 is safe
with multiple imported modules and with classes hierarchies. Number 1
is much restrictive, but you know when you're doing something fishy.
- - -
That said, a property keyword may also have some overloading problems
to solve; it can't behave excaty as a function:
class X
{
property void delegate(float) foo() { ... }
property void foo(void delegate(float) f) { ... }
void foo(float f) { ... }
void blah() { foo(1.0); } // what is this?
}
You'll need a rule to forbid overloaded functions that mix property and
non-property. That is, in class X and any derived class.
Also, overload sets accross modules will need to be revised to become
ambiguous when not all members are properties or non-properties. For
instance, this would need to become ambiguous:
module a;
property void delegate(int) foo();
module b;
int foo(float);
module c;
import a, b;
unittest
{
foo(1); // which one?
}
This applies to a "getFoo()" syntax too.
And to compensate that +1 for you above, I'd point out that there is an
alternative with no case issue (get_thing/set_thing) and that your proposal
requires a keyword.
Then let's introduce annotations and be done with it. No more pure,
shared, __gshared, nothrow, and probably a whole slew of other silly
attribute keywords.
To me, wether the keyword is "property" or a "@property" annotation, I
don't really care, both are fine with me. I still find
"getFoo()"/"setFoo()" simpler and aesthetically better, but as I said
before, the property keyword (be it a keyword or an annotation) is
acceptable to me.
About your idea, I find it confusing that (&something) and &(something) may
not have the same meaning.
That's true. Then again, how often do you need to get the address of
a returned ref value?
Every time you want to pass it to a C API.
That said, perhaps I have a solution for that problem. The compiler
could be smart about it, just like it already is when you take the
address of an overloaded function: it could check if the variable you
put the address into match the type of the property in addition to the
type of the setter and the type of the getter.
property ref int something();
property void something(int s);
int delegate() getter = &something; // address of getter
void delegate(int) setter = &something; // address of setter
int* value = &something; // address of returned ref value
Obviously, this doesn't work with auto, but that's a general problem
with overloading, not something inehrent to properties.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: OS X Installer
On 2009-08-01 20:15:41 -0400, Sergey Gromov said: Here's a nice document about directory layout in UNIX-like OSes: http://www.pathname.com/fhs/pub/fhs-2.3.html I think MacOS should follow this layout at least in part. In particular /usr/local/ is used for locally installed packages which otherwise respect the standard directory structure found in / or /usr/. That is, binaries go into /usr/local/bin/, libraries in /usr/local/lib/ etc. If a package wants to keep its own structure it's supposted to go into /opt/, like /opt/dmd2/whatever. Well, given that this is Mac OS X we could also put this in /Library/D/dmd and /Library/D/dmd2, two directories which aren't hidden by the file browser. Then put symlinks in /usr/local/bin and /usr/local/lib pointing there. Users will then be able to upgrade without an installer by simply replacing the folder at /Library/D/dmd & dmd2 with a newly downloaded one. I think that's better than /opt, as /opt isn't present by default on Mac OS X, isn't hidden by the Finder when present (contrary to all other "UNIX" directories at the root) and thus would look a little out of place on the hard drive. And there's already /Library/Python, /Library/PHP and /Library/Ruby in that /Library directory to set a precedent. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: new DIP5: Properties 2
Sergey Gromov wrote:
Fri, 31 Jul 2009 21:37:06 -0500, Andrei Alexandrescu wrote:
To clarify: if there was any extra checking by the compiler, any
guarantee that the feature would provide at all, I'd be glad to pay the
price of thinking more when putting together a design. But you want to
define a language feature that allows people to require "()" or not as
they please, and that's all. It's a frivolous detail to be spending time
on when designing an API. I simply don't believe that's good language
design.
That's not "all." To me it's mostly maintainability.
If there is a property 'foo' and you allow to set it both as 'foo = 5'
and 'foo(5)' then somebody *will* use the foo(5) form. Making it hard,
or even impossible for you, the maintainer, to switch from a property
back to a regular field for 'foo'.
If you allow to call function 'bar()' both with and without parentheses,
and a project is maintained by more than one person, they *will* call it
differently making the source look inconsistent.
Dropping the 'omittable parentheses' thing happens to solve these, and
the delegate return problem, and helps to disambiguate words with
overloaded meanings.
Thanks for these great points. As an additional example, most ranges
define the method
bool empty() { ... }
whereas infinite ranges define the enum
enum bool empty = false;
It follows that if a range user wants to be compatible with finite and
infinite ranges, they always must use no "()". It would be nice if the
range's definition could enforce that.
Andrei
Re: OS X Installer
Sat, 1 Aug 2009 07:55:08 -0400, Michel Fortin wrote:
> On 2009-08-01 04:41:38 -0400, Anders F Björklund said:
>
>> Jacob Carlborg wrote:
>>
Speaking of that OS X DMD installer, are you sure installing it at
/usr/share/dmd/ is a good idea? [...]
>>> I looked at a gdc installer and looked where it placed the compiler and
>>> did the same. I don't know where it's best to place the compiler.
>>
>> You can use /opt/dmd and /opt/dmd2, if you don't
>> want to use the regular file hierarchy in hier(7)
>>
>> DMD = /opt/dmd2/osx/bin/dmd
>>
>> Or you can use e.g. /usr/local/bin and rename to
>> dmd2 and dmd2.conf (which takes some trickery...)
>>
>> DMD = dmd2
>
> In hier(7), it says that "/usr/local" is for "executables, libraries,
> etc. not included by the basic operating system", so I guess DMD fits
> this quite well.
>
> I'm preparing an installer for D for Xcode and made it install DMD at
> /usr/local/dmd and /usr/local/dmd2, with symlinks at /usr/local/bin/dmd
> (system-prefered version) /usr/local/bin/dmd1 (1.x) and
> /usr/local/bin/dmd2 (2.x). This makes it easy to choose the version you
> want within Xcode.
>
> For some reasons, the symlinks works fine with Xcode. But they aren't
> working from the command line (dmd complains that it can't find
> object.o). I've made a small C program to replace the symlink:
>
> #include
>
> int main(unsigned int argc, char **argv) {
> argv[0] = "/usr/local/dmd/osx/bin/dmd";
> execv("/usr/local/dmd/osx/bin/dmd", argv);
> }
>
> No more problem from the command line.
Here's a nice document about directory layout in UNIX-like OSes:
http://www.pathname.com/fhs/pub/fhs-2.3.html
I think MacOS should follow this layout at least in part. In particular
/usr/local/ is used for locally installed packages which otherwise
respect the standard directory structure found in / or /usr/. That is,
binaries go into /usr/local/bin/, libraries in /usr/local/lib/ etc. If
a package wants to keep its own structure it's supposted to go into
/opt/, like /opt/dmd2/whatever.
Re: DIP guidelines [was: DIP6: Attributes]
Leandro Lucarella, el 1 de agosto a las 20:28 me escribiste: > Ary Borenszweig, el 1 de agosto a las 16:29 me escribiste: > > http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 > > Please, try to post at least the abstract of the DIP with the link, so > people can easily know what is it about =) BTW, you forgot to link the DIP to the DIPs index: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs It's linked now... =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) Home, home again. I like to be here when I can. When I come home cold and tired It's good to warm my bones beside the fire.
Re: DIP6: Attributes
Ary Borenszweig, el 1 de agosto a las 16:29 me escribiste:
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
I really think that D should support some kind of annotations. I think
it's a good idea to add them in stages. I could add that in the first
stage, old-style attributes/whatever (override, deprecated, etc.) should
be accepted too (i.e. without the leading @). Then people complaining
about backward compatibility can be happy (me included; hey! I'll add them
to D1.1 too! ;). New syntax can make use of annotations though (hello
properties!).
I think annotations in D can reach their peak of utility when AST macros
get implemented. I think it would be great being able to "register"
annotation handlers to the compiler to do arbitrary transformations to the
code. You could even move a big part of the compiler implementation to
library code using annotations and AST macros. But this have to come in
other stages for sure.
I think changing the FE to allow annotation syntax wouldn't be very hard
(I'm guessing, I never hacked the DMDFE myself). Maybe someone who played
with the FE can make a quick patch as a proof of concepts, even if the
implementation ignores the annotations completely for now it can be a good
start.
I think the "Other thoughts" section should be official part of the
proposal if there is any intention to move most of the current attribute
keywords to annotations.
About the version(X) {} else {}, first, version(!X) could be supported as
an ugly hack =P. A more generic approach could be to support annotations
returns. Annotations could return void (in which case the else statement
is a *semantic* error) or bool (in which case the else statement is
supported). The problem with this is that statements should be target for
annotations too, so one can do:
@deprecated
void foo()
{
@version(Foo) writeln("foo");
}
Maybe this one should be delayed for a second stage of annotations =)
--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
CHINO ATRAPA COTORRAS
-- Crónica TV
Re: new DIP5: Properties 2
Fri, 31 Jul 2009 21:37:06 -0500, Andrei Alexandrescu wrote: > To clarify: if there was any extra checking by the compiler, any > guarantee that the feature would provide at all, I'd be glad to pay the > price of thinking more when putting together a design. But you want to > define a language feature that allows people to require "()" or not as > they please, and that's all. It's a frivolous detail to be spending time > on when designing an API. I simply don't believe that's good language > design. That's not "all." To me it's mostly maintainability. If there is a property 'foo' and you allow to set it both as 'foo = 5' and 'foo(5)' then somebody *will* use the foo(5) form. Making it hard, or even impossible for you, the maintainer, to switch from a property back to a regular field for 'foo'. If you allow to call function 'bar()' both with and without parentheses, and a project is maintained by more than one person, they *will* call it differently making the source look inconsistent. Dropping the 'omittable parentheses' thing happens to solve these, and the delegate return problem, and helps to disambiguate words with overloaded meanings.
DIP guidelines [was: DIP6: Attributes]
Ary Borenszweig, el 1 de agosto a las 16:29 me escribiste: > http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Please, try to post at least the abstract of the DIP with the link, so people can easily know what is it about =) And when writing a DIP, try to make the abstract a little more descriptive. From an abstract you should be able to tell what the DIP is about (in this case explain what an annotation is at least). A oneliner is not good enough, that's just a title, not an abstract. If it's too hard to explain, try to provide a link to somewhere else where the terms are described. The rationale can be a little more descriptive too. What are the advantages of removing keywords for example? Use NG posts links if you have some problems documented there, for example. Try not to explain your opinion in DIPs. They are not NG posts, they should provide facts and be as objective as possible. Even when that's pretty hard, saying "I prefer Java's one because ..." is excessively subjective. Avoid doing that. You can express the same by saying something like "Java syntax has the advantage of ..." for example. A section called "Other thoughts" is not very serious either. If you are not yet convinced about something in the DIP, post it in the announcement post in the NG so it can be discussed and added later to the DIP when the idea is in better shape. Please, don't take this personally, I just want DIPs to be high quality, otherwise they will never be taken seriously. =) I've added this information in a Recommendations subsection to the DIP1, see: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1#Recommendations I'll address the DIP itself in another post ;) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) HOMBRE DESNUDO AMENAZA A LOS VECINOS CON UNA "KATANA" DESDE SU BALCON -- Crónica TV
Re: Omissible Parentheses...
On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn wrote: Robert Jacques wrote: I like them too (a lot). I find they increase the clarity of my code (particularly function chaining). I think that when you find you need to use function-chaining, the functions (except possibly the rightmost) are often meant to be properties/fields. That's why they would look more natural without parentheses. Nope. I meant _function_ chaining. This comment comes mostly from using std.string and std.algorithm, whose functions don't behave as fields. Both of these libraries show off the power you get from the flexibility of function call / property duality. I've also used toggle/flag setting methods in this way. It's concise, clean and very understandable.
Re: DIP6: Attributes
Robert Fraser wrote: > Ary Borenszweig wrote: >> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 > > I think annotations are a good idea, but turning keywords already in the > language into annotations seems kinda pointless & would kill backwards > compatibility. In C#/Java some things are modifiers while others are > annotations -- and with good reason. > > IMO, the focus of annotations should be mostly on things _external_ to > the compiler. So, serializability, thread safety, etc. Really, I think > annotations should be for compile-time reflection (so like someone else > said __traits(annotations, symbol) should return a tuple of annotation > structs. Seconded. Annotations sound like a useful feature especially if they can be created and manipulated by the programmer, which would require syntactic distinction. I never did much care for java's annotation syntax, but I do think turning most if not all of the keywords mentioned into annotations is a good idea, at least behind the scenes. Off the top of my head, it could solve the function <-> delegate ref parameter problem.
Re: DIP6: Attributes
Ary Borenszweig wrote: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 I think annotations are a good idea, but turning keywords already in the language into annotations seems kinda pointless & would kill backwards compatibility. In C#/Java some things are modifiers while others are annotations -- and with good reason. IMO, the focus of annotations should be mostly on things _external_ to the compiler. So, serializability, thread safety, etc. Really, I think annotations should be for compile-time reflection (so like someone else said __traits(annotations, symbol) should return a tuple of annotation structs.
Re: DIP6: Attributes
Tim Matthews wrote: On Sat, 01 Aug 2009 16:29:28 -0300 Ary Borenszweig wrote: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Are pragmas not already here for this? Nope, they're for compiler-specific extensions
Re: YAPP - D properties voting reminder
On Sat, 01 Aug 2009 15:28:36 -0400 Chad J wrote: There are probably others who only check the > newsgroup every few days. Please give it some time. I would check the ng more often if it could upgrade it's server / bandwidth or wherever the bottle neck is.
Re: DIP6: Attributes
On Sat, 01 Aug 2009 16:29:28 -0300 Ary Borenszweig wrote: > http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Are pragmas not already here for this?
Re: property / getProperty() / setProperty()
On Sat, Aug 1, 2009 at 4:01 PM, Michel Fortin wrote:
>> 3. There is no naming ambiguity.
>
> A set/get prefix removes pretty much all ambiguity too.
>
> I mean, the current syntax is "T transform()" and you can't know if
> transform is a noun or a verb. With my prefix it's "T getTransform()" which
> makes it pretty clear what it does. With yours it's "property T transform()"
> and it's pretty clear too.
class X
{
int foo;
int getFoo() { return 5; }
int blah() { return foo; /* um.. which? */ }
}
> And to compensate that +1 for you above, I'd point out that there is an
> alternative with no case issue (get_thing/set_thing) and that your proposal
> requires a keyword.
Then let's introduce annotations and be done with it. No more pure,
shared, __gshared, nothrow, and probably a whole slew of other silly
attribute keywords.
> About your idea, I find it confusing that (&something) and &(something) may
> not have the same meaning.
That's true. Then again, how often do you need to get the address of
a returned ref value?
Re: DIP6: Attributes
"Adam D. Ruppe" wrote in message news:mailman.258.1249155638.14071.digitalmar...@puremagic.com... > On Sat, Aug 01, 2009 at 04:29:28PM -0300, Ary Borenszweig wrote: >> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 > > What's the difference between this and a keyword? It seems to be a keyword > with a different name. > It doesn't reduce the pool of available identifier names since user-created identifiers can't contain @ anyway (at least I don't think they can). Plus, (down the road, with the reflection stuff you mentioned) it would be possible to create new annotations purely in a library without requiring changes to the language or compiler.
Re: property / getProperty() / setProperty()
"Andrei Alexandrescu" wrote in message news:h51q1b$lh...@digitalmars.com... > bearophile wrote: >> Andrei Alexandrescu: >>> Thanks. So it looks like get_property() and set_property() could fly. >>> How does that sound? >> >> Not too much good. Among the simpler solutions there's the 'property' >> attribute, that while not helping in reducing code (it makes code >> longer!) solves most problems, while being simple. It's the minimal >> solution that I think will work/fly. > > We can't throw keywords at problems like they're getting out of style. > I've noticed that here every little problem gets solved by a little > keyword. If not, some arcane new syntax. Nobody seems to care about > rewriting, which I think is best. > That's because most people don't think it's best. Your solution only addresses the user of the property. From that perspective, yes your rewriting approach works perfectly fine. But what you're (mostly) sweeping under the rug is the creator of the property. Properties are such a common idiom that their definitions shouldn't be such a verbose non-DRY pain-in-the-ass to read and create. Additionally, I can't believe you're so steadfast about saving the three keystokes for '()' (even at the expense of creating certain unsolvable problems), and yet you seem to have no problem at all with the far-more-than-three extra keystrokes required by throwing away brevity and DRY when creating a property under the rewrite proposals.
Re: property / getProperty() / setProperty()
Ary Borenszweig wrote: Andrei Alexandrescu escribió: bearophile wrote: Andrei Alexandrescu: Thanks. So it looks like get_property() and set_property() could fly. How does that sound? Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly. We can't throw keywords at problems like they're getting out of style. Hey! Let's introduce pure functions --> the new "pure" keyword was added. Hey! Let's introduce functions that don't throw --> the new "nothrow" keyword was added. Hey! Let's introduce thread local storage --> "shared" and "__gshared" keyword added. Hey! Let's introduce... annotations and stop adding keywords for every new feature. For the record, I didn't like most of these. Andrei
Re: property / getProperty() / setProperty()
Jarrett Billingsley wrote: > On Sat, Aug 1, 2009 at 2:38 PM, Ary Borenszweig wrote: >> auto a = x; // OK >> auto a = x(); // Wrong >> x = 2; // OK >> x(2); // Wrong > > And furthermore, I mentioned that &obj.foo would always get the > address of the member 'foo' from 'obj', even if 'foo' was a property. That's the part of this proposal I don't like. The getter of a property is not the property itself, and should not have the same name. It's confusing that '&x.y' is a delegate but 'x.y' is not a method. In short, this proposal fails to fix the conceptual problem with the way properties are handled in D right now. -- Rainer Deyke - rain...@eldwood.com
Re: property / getProperty() / setProperty()
aarti_pl escribió: bearophile pisze: aarti_pl: What you mean saying "attributes"?< See for example: http://en.wikipedia.org/wiki/Java_annotation It's not an esoteric thing, It's a way to add some extra semantics to a program. In a low-level language like D there are other possible purposes for annotations/attributes (that aren't useful in Java), you can add semantics that helps avoid bugs or can be used by the optimizer to increase the efficiency of the compiled program (GCC too has some of such function/variable attributes), I can show some examples. Bye, bearophile Thanks for answer! I know Java annotations - I just didn't know what you meant saying "attribute". Ah, it's because in C# they are called attributes. You know, C# and Java always try to come up with the same things but with different names. :-P
Re: property / getProperty() / setProperty()
On 2009-08-01 11:56:23 -0400, Jarrett Billingsley said: It's been mentioned before, and I'll mention it again: a simple 'property' attribute that can be applied to any function. No new syntax, no get/set/value 'magic' keywords, just 'property.' Applying it to a function makes the compiler enforce the property syntax when using the functions. Any function that doesn't have the property attribute - which should be most functions - can't be treated as one. It doesn't require any special support from the compiler beyond what it currently does. It doesn't require any 'magic'. It doesn't require any verbose syntax. It solves pretty much all the problems. That wasn't addressed to me, but since I started this thread, I feel I should answer. What problems does your proposal solve that aren't solved by a naming convention and the compiler following that convention to enable the property syntax? From what I see, you prefer adding a property keyword over a naming convention. That's fine, but I think otherwise. Let's compare them on a technical level using your checklist: 1. You can no longer call functions as properties that were never intended to be (writeln = 4; goes away). Same as with a get/set prefix, except that you can now explicitly call getSomething()/setSomething() if you want (a minor advantage in my opinion). 2. The "obj.prop(args)" ambiguity goes away. *Either* obj.prop is a normal method function and (args) are passed to it, *or* obj.prop has the "property" attribute, and (args) are passed to its result. Stuff like "obj.prop[i]" is the same way. Either obj.prop binds to a real function, or it isn't really there and the compiler maps it to getProp/setProp as needed. Same thing for "obj.prop[i]", which would be equivalent to "obj.getProp()[i]" if there is no "prop" member in "obj". So both proposals are as good in this respect. 3. There is no naming ambiguity. A set/get prefix removes pretty much all ambiguity too. I mean, the current syntax is "T transform()" and you can't know if transform is a noun or a verb. With my prefix it's "T getTransform()" which makes it pretty clear what it does. With yours it's "property T transform()" and it's pretty clear too. 4. There are no case issues. Indeed. +1 for your proposal. 5. It provides useful semantic information to tools, IDEs, and reflection. With a get/set prefix too you can get useful information about what you can set and get too. Sure you assume that get means get and set means set, just like you assume that everything using the property keyword is really meant to be a property with your proposal. (Both systems can be abused as easily, that's my point.) 6. It's nonintrusive and self-documenting. I'm not sure if you'd find a get/set prefix non-intrusive or not (I don't), but I find it as self-documenting as a property keyword. And to compensate that +1 for you above, I'd point out that there is an alternative with no case issue (get_thing/set_thing) and that your proposal requires a keyword. I have nothing against your proposal. I prefer the aestetics of mine and I believe they're both pretty equal on technical ground. The *only* technical issue I can come up with is if you had "property ref X foo()", where foo returned a reference to some value type. Then you do "&obj.foo" - what does this get the address of? To that end, I suggest that &obj.foo always gets the address of the member or method 'foo' from object 'obj', and &(obj.foo) would get the address of the return value of obj.foo. The extra parens in there say "really, I want you to evaluate the thing inside *first*". Interesting. That's a problem that doesn't exist with with the naming convention proposal. About your idea, I find it confusing that (&something) and &(something) may not have the same meaning. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: property / getProperty() / setProperty()
Andrei Alexandrescu escribió: bearophile wrote: Andrei Alexandrescu: Thanks. So it looks like get_property() and set_property() could fly. How does that sound? Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly. We can't throw keywords at problems like they're getting out of style. Hey! Let's introduce pure functions --> the new "pure" keyword was added. Hey! Let's introduce functions that don't throw --> the new "nothrow" keyword was added. Hey! Let's introduce thread local storage --> "shared" and "__gshared" keyword added. Hey! Let's introduce... annotations and stop adding keywords for every new feature.
Re: Omissible Parentheses...
Robert Jacques wrote: > I like them too (a lot). I find they increase the clarity of my code > (particularly function chaining). I think that when you find you need to use function-chaining, the functions (except possibly the rightmost) are often meant to be properties/fields. That's why they would look more natural without parentheses. -- Michiel Helvensteijn
Re: property / getProperty() / setProperty()
bearophile pisze: aarti_pl: What you mean saying "attributes"?< See for example: http://en.wikipedia.org/wiki/Java_annotation It's not an esoteric thing, It's a way to add some extra semantics to a program. In a low-level language like D there are other possible purposes for annotations/attributes (that aren't useful in Java), you can add semantics that helps avoid bugs or can be used by the optimizer to increase the efficiency of the compiled program (GCC too has some of such function/variable attributes), I can show some examples. Bye, bearophile Thanks for answer! I know Java annotations - I just didn't know what you meant saying "attribute". BR Marcin Kuszczak (aarti_pl)
Re: Omissible Parentheses...
On Sat, 01 Aug 2009 13:05:26 -0400, Denis Koroskin <2kor...@gmail.com> wrote: On Sat, 01 Aug 2009 21:04:43 +0400, Chad J wrote: Omissible Parentheses Could someone remind me why we don't remove these? So far I have - They save typing. - Removing them breaks backwards compatibility. - They allow some features of properties, but with a list of limitations and gotchas. This is not intended to be a deep discussion. I'm writing a piece on properties, so I'm gathering information. Andrei likes them. I like them too (a lot). I find they increase the clarity of my code (particularly function chaining).
Re: DIP6: Attributes
Adam D. Ruppe escribió: On Sat, Aug 01, 2009 at 04:29:28PM -0300, Ary Borenszweig wrote: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 What's the difference between this and a keyword? It seems to be a keyword with a different name. A keyword means changing the lexer, the parser and the semantic analysis. Annotations means only changing the semantic analysis (ok, changing the lexer and parser also, but just the first time to implement annotations). And if the first stage is implemented, what you describe below could also be implemented. As the DIP says, the advantage is also reducing the huge amount of keywords that exist now in the language. For this annotation thing to be really useful, I'd think it should be well, dynamic for lack of a better word. You can just list them on an item, then inspect them later in templates: @magic int a; [...] auto annotations = __traits(annotations, a); assert(annotations[0] == "magic"); // now you can do whatever with this I wished I had something like this before, but I forgot why But if you aren't proposing something like that being possible, then what's the point of the @ to a keyword? It doesn't seem to be any different. I could have included that in the DIP. But you have to start with small things, simple things, and evolve from that point. The DIP is just about how to start introducing annotations in the language with minimal changes to what exists now.
Re: property / getProperty() / setProperty()
aarti_pl: > What you mean saying "attributes"?< See for example: http://en.wikipedia.org/wiki/Java_annotation It's not an esoteric thing, It's a way to add some extra semantics to a program. In a low-level language like D there are other possible purposes for annotations/attributes (that aren't useful in Java), you can add semantics that helps avoid bugs or can be used by the optimizer to increase the efficiency of the compiled program (GCC too has some of such function/variable attributes), I can show some examples. Bye, bearophile
Re: DIP6: Attributes
Ary Borenszweig pisze: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Nice! This proposal seems to be really better (more general and extensible) than any property proposal before. BR Marcin Kuszczak (aarti_pl)
Re: DIP6: Attributes
On Sat, Aug 01, 2009 at 04:29:28PM -0300, Ary Borenszweig wrote: > http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 What's the difference between this and a keyword? It seems to be a keyword with a different name. For this annotation thing to be really useful, I'd think it should be well, dynamic for lack of a better word. You can just list them on an item, then inspect them later in templates: @magic int a; [...] auto annotations = __traits(annotations, a); assert(annotations[0] == "magic"); // now you can do whatever with this I wished I had something like this before, but I forgot why But if you aren't proposing something like that being possible, then what's the point of the @ to a keyword? It doesn't seem to be any different. -- Adam D. Ruppe http://arsdnet.net
Re: Reading bool as the string "true" or "false"
Ali Cehreli wrote: If the default behavior for dout.writefln is to print bool values as the "true" and "false" strings, then the opposite should be available and arguably be the default: // "true" and "false" should be acceptable inputs: bool b; din.readf(&b); Am I wrong? Thanks, Ali P.S. There hasn't been any responses to the same question that I asked at the .learn forum: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=17291 Open a bug; the newgroups aren't the right place for this. Thanks!
Re: YAPP - D properties voting reminder
Chad J pisze: aarti_pl wrote: I don't think that 23 voters can be representative for D community. If you have clear opinion about how properties should work in D, then you can express your opinion. Don't loose your chance :-) The poll has been up for a bit more than 5 hours now, and 34 people have voted. This /might/ be /almost/ representative of the highly active D community. There are probably others who only check the newsgroup every few days. Please give it some time. I agree. We can already see preliminary results, but I think that the poll should stay till next Sunday (9. August). I will try to send reminders every few days. BR Marcin Kuszczak (aarti_pl)
DIP6: Attributes
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
Re: DIP6: Attributes
Ary Borenszweig escribió: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6 Ouch. I meant: DIP6: Annotations.
Re: YAPP - D properties voting reminder
aarti_pl wrote: > > I don't think that 23 voters can be representative for D community. If > you have clear opinion about how properties should work in D, then you > can express your opinion. Don't loose your chance :-) > The poll has been up for a bit more than 5 hours now, and 34 people have voted. This /might/ be /almost/ representative of the highly active D community. There are probably others who only check the newsgroup every few days. Please give it some time.
Re: YAPP - D properties - voting
aarti_pl wrote: > Ary Borenszweig pisze: >> >> That's because we can't see who is voting and if anyone is cheating. > > Trivial cheating is rather not possible - there is only one voice per IP. > > BR > Marcin Kuszczak > (aarti_pl) Interesting. I can't tell because it seems like I can still submit after voting, but I don't want to test it for fear of double-voting.
Re: property / getProperty() / setProperty()
Jarrett Billingsley wrote: On Sat, Aug 1, 2009 at 1:38 PM, Andrei Alexandrescu wrote: Of course they're overridable. They are *functions*. Then why are you calling them properties? :o) Stop deliberately misunderstanding me. Yeah, sorry. Low blow. I shouldn't have sent out that crap. Andrei
Re: property / getProperty() / setProperty()
bearophile pisze: > I agree, attributes (or something like that) are a better solution to this (and other) problem. What you mean saying "attributes"? Probably I missed some posts... BR Marcin Kuszczak (aarti_pl)
Re: YAPP - D properties - voting
Ary Borenszweig pisze: Andrei Alexandrescu escribió: Leandro Lucarella wrote: aarti_pl, el 1 de agosto a las 16:44 me escribiste: Ok. Let's do some voting. I extended pool with latest syntax suggestion. I also added additional pool about omissible parenthesis feature. Here is the link: http://www.igsoft.net/dpolls/index.php Let's vote and please do not kill my server ;-) This is getting ridiculous, we have as many property proposals as voting systems now... OMFG! It is ridiculous, particularly in light of the fact that no poll shows the landslide prevalence of "everybody". That's because we can't see who is voting and if anyone is cheating. Trivial cheating is rather not possible - there is only one voice per IP. BR Marcin Kuszczak (aarti_pl)
Re: property / getProperty() / setProperty()
Andrei Alexandrescu: > We can't throw keywords at problems like they're getting out of style. > I've noticed that here every little problem gets solved by a little > keyword. If not, some arcane new syntax. I agree, attributes (or something like that) are a better solution to this (and other) problem. Anyway, this discussion is going in circles :-) Bye, bearophile
Re: YAPP - D properties - voting
Andrei Alexandrescu escribió: Leandro Lucarella wrote: aarti_pl, el 1 de agosto a las 16:44 me escribiste: Ok. Let's do some voting. I extended pool with latest syntax suggestion. I also added additional pool about omissible parenthesis feature. Here is the link: http://www.igsoft.net/dpolls/index.php Let's vote and please do not kill my server ;-) This is getting ridiculous, we have as many property proposals as voting systems now... OMFG! It is ridiculous, particularly in light of the fact that no poll shows the landslide prevalence of "everybody". That's because we can't see who is voting and if anyone is cheating.
Re: property / getProperty() / setProperty()
On Sat, Aug 1, 2009 at 2:38 PM, Ary Borenszweig wrote:
> Rainer Deyke escribió:
>>
>> Ary Borenszweig wrote:
>>>
>>> The "property" just signals that the function is a property. But it's
>>> still a function and all of the previous rules that existed are still
>>> valid.
>>
>> My problem with the 'property' syntax:
>>
>> Possibility 1: the property still acts like a function, so you can still
>> do 'x.a()' when you mean 'x.a'.
>>
>> Possibility 2: the property does not act like a function, so you can no
>> longer get a delegate to the property getter.
>>
>> Possibility 3: the property sometimes acts like a function and sometimes
>> not, and you haven't defined the distinction.
>
> None of those are correct. See Jarrett's post.
>
> property {
> int x() { }
> int x(int a) { }
> }
>
> auto a = x; // OK
> auto a = x(); // Wrong
> x = 2; // OK
> x(2); // Wrong
And furthermore, I mentioned that &obj.foo would always get the
address of the member 'foo' from 'obj', even if 'foo' was a property.
But hey, it's not like it matters anyway. We're pissing in the ocean.
Re: property / getProperty() / setProperty()
Rainer Deyke escribió:
Ary Borenszweig wrote:
The "property" just signals that the function is a property. But it's
still a function and all of the previous rules that existed are still
valid.
My problem with the 'property' syntax:
Possibility 1: the property still acts like a function, so you can still
do 'x.a()' when you mean 'x.a'.
Possibility 2: the property does not act like a function, so you can no
longer get a delegate to the property getter.
Possibility 3: the property sometimes acts like a function and sometimes
not, and you haven't defined the distinction.
None of those are correct. See Jarrett's post.
property {
int x() { }
int x(int a) { }
}
auto a = x; // OK
auto a = x(); // Wrong
x = 2; // OK
x(2); // Wrong
Re: property / getProperty() / setProperty()
Ary Borenszweig wrote: > The "property" just signals that the function is a property. But it's > still a function and all of the previous rules that existed are still > valid. My problem with the 'property' syntax: Possibility 1: the property still acts like a function, so you can still do 'x.a()' when you mean 'x.a'. Possibility 2: the property does not act like a function, so you can no longer get a delegate to the property getter. Possibility 3: the property sometimes acts like a function and sometimes not, and you haven't defined the distinction. All three possibilities are messy, and I can't tell from your proposal which one will apply. get_foo/set_foo is better in this regard, plus it doesn't require yet another keyword. -- Rainer Deyke - rain...@eldwood.com
Re: property / getProperty() / setProperty()
On Sat, Aug 1, 2009 at 1:38 PM, Andrei Alexandrescu wrote: >> Of course they're overridable. They are *functions*. > > Then why are you calling them properties? :o) Stop deliberately misunderstanding me. >> So let me get this straight: the property attribute would be better >> technically, but let's not throw more keywords at it; so instead we suggest >> attributes, but no, they don't have any useful purpose. >> >> WHAT. > > I didn't say that. Whatever. Have fun designing your own language, Andrei. Must be nice.
Re: YAPP - D properties - voting
Andrei Alexandrescu wrote: > It is ridiculous, particularly in light of the fact that no poll shows > the landslide prevalence of "everybody". Not everyone may agree, or understand. But if you look at it objectively, D's 'properties' cause inconsistencies, ambiguities and limitations. I'm not listing them again, since it doesn't seem to have any effect. I fully understand that the simple rewriting rules currently used were by far the easiest way to get properties into D. No extra syntax or anything. Walter probably only needed a day or two to put them into the compiler. Not much thought had to go into it. This is evident by the fact that +=, ++, etc. don't work. And then you could advertise that D had properties. Then some people started to abuse property syntax to save three keystrokes (one for the shift-key). So now all of a sudden, real properties can't ever work for D, since you'd lose your no-parentheses function-calls, and some backwards compatibility. But it is a flawed design. Many people have tried to explain this to you. But when faced with the facts, both you and Walter avoid the issue. You focus on minor mistakes in peoples posts and then ignore their real message. And often you simply never reply. Take, for example: http://www.digitalmars.com/d/archives/digitalmars/D/Reddit_why_aren_t_people_using_D_93528.html#N93753 I don't think D will soon adopt the kind of properties some of us have been advocating. You'll just treat the symptoms, I expect. This post is not meant to convince you. It simply needed to be said. I apologize for my confrontational tone. -- Michiel Helvensteijn
YAPP - D properties voting reminder
Hello!
It is reminder about ongoing voting about D properties proposals. You
can express your opinion.
Current results are as follows:
* 23 voters
* D properties pool:
- 60,87% of people are for introducing new syntax for properties
- 39,13% are for fixing existing problems with current syntax
- most people who would like new syntax prefer following syntax:
property {
int size() {return _size;}
void size(int s) {_size = s;}
}
then goes C# syntax, and finally latest proposal from Michael Fortin.
* Omissible parenthesis poll:
- 65,22% are for removing omissible parenthesis syntax from D language
---
I don't think that 23 voters can be representative for D community. If
you have clear opinion about how properties should work in D, then you
can express your opinion. Don't loose your chance :-)
http://www.igsoft.net/dpolls/index.php
BR
Marcin Kuszczak
(aarti_pl)
Re: property / getProperty() / setProperty()
Jarrett Billingsley wrote: "Andrei Alexandrescu" wrote in message news:h51rnq$o2...@digitalmars.com... Jarrett Billingsley wrote: I'll ask again: do you have any *technical* issues with the 'property' attribute suggestion? My main technical issue is throwing a keyword at a very minor issue. Yeah, it is pretty minor, huh? I mean, it's not like it's been the center of discussion for the past week. And no one has ever complained about it before. Downplaying the size of the issue at hand doesn't make it go away. Once the keyword is in the mix, we need to define how it interacts with everything else (e.g., are properties overridable?) Of course they're overridable. They are *functions*. Then why are you calling them properties? :o) They do everything exactly the same as other functions. *All* the property attribute would do is enforce a property syntax at the use site instead of a function call syntax. Oh, so it is minor. A solution based on rewrites is considerably simpler and more in according with the size of the problem. A solution based on rewrites has a pretty horrible problem with name ambiguity. And this isn't even a technical concern; you're just saying again that the problem is minor. You have not presented any technical arguments against the property attribute suggestion. So let me get this straight: the property attribute would be better technically, but let's not throw more keywords at it; so instead we suggest attributes, but no, they don't have any useful purpose. WHAT. I didn't say that. Andrei
Re: YAPP - D properties - voting
Leandro Lucarella wrote: aarti_pl, el 1 de agosto a las 16:44 me escribiste: Ok. Let's do some voting. I extended pool with latest syntax suggestion. I also added additional pool about omissible parenthesis feature. Here is the link: http://www.igsoft.net/dpolls/index.php Let's vote and please do not kill my server ;-) This is getting ridiculous, we have as many property proposals as voting systems now... OMFG! It is ridiculous, particularly in light of the fact that no poll shows the landslide prevalence of "everybody". Andrei
Re: Omissible Parentheses...
Denis Koroskin wrote: On Sat, 01 Aug 2009 21:04:43 +0400, Chad J wrote: Omissible Parentheses Could someone remind me why we don't remove these? So far I have - They save typing. - Removing them breaks backwards compatibility. - They allow some features of properties, but with a list of limitations and gotchas. This is not intended to be a deep discussion. I'm writing a piece on properties, so I'm gathering information. Andrei likes them. http://igsoft.net/dpolls/poll/results.php?pollid=1 http://igsoft.net/dpolls/poll/results.php?pollid=2 Andrei
Re: Omissible Parentheses...
On 2009-08-01 13:05:26 -0400, "Denis Koroskin" <2kor...@gmail.com> said: On Sat, 01 Aug 2009 21:04:43 +0400, Chad J wrote: Omissible Parentheses Could someone remind me why we don't remove these? So far I have - They save typing. - Removing them breaks backwards compatibility. - They allow some features of properties, but with a list of limitations and gotchas. This is not intended to be a deep discussion. I'm writing a piece on properties, so I'm gathering information. Andrei likes them. I like them too, despite their gotchas. If they were not cause for special rules when returning delegates, also classes and structs with an opCall member, I'd want to keep them. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: property / getProperty() / setProperty()
On 2009-08-01 11:31:17 -0400, Andrei Alexandrescu
said:
Michel Fortin wrote:
I hope this proposal can rally more that divide... let's see.
Andrei said this in another thread about adding a property keyword in
front of functions to make them properties:
The problem is that it's all loss, no gain: the callee must make the
decision whether the call must be with or without parens, and the caller
must obey that decision. There is no guarantee gained, only effort.
I see your point Andrei: it's little gain to add a syntax that's just a
modifier to a function to decide how you must call it.
That's a great summary.
I also see the point of all those arguing that it's important to be
able to distinguish between a property and an action, and that the
english laguage is not expressive enough to make that distinction clear
in a lot of cases.
I understand that point too.
I know, I've written programming guidelines[1] and tried very hard to
make this problem go away by mandating "is", "has" or a modal verb as a
prefix for boolean attributes in the guidelines, only to be stuck with
no solution for the "transform" example from Bill Baxter (thread
"Properties - another one that gets me") which isn't boolean and for
which you can't really add a prefix that makes sense.
[1]: http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines
Good point.
The best simple solution to that property problem I've seen up to now
is to define "getProperty" and "setProperty" and have the compiler
automatically check for these functions when it encounters the
"property" symbol.
Why do I favor "getThing" and "setThing" over "opGet_thing" and
"opSet_thing"? Because the later are ugly. Please don't underestimate
aestetics and readability as those are the key to make the language
enjoyable to use and what the beginners will judge the language from.
Also, the pattern will be pretty familiar to those comming from Java
and elsewhere. And finally, for those who don't like having a property
syntax, they can ignore properties completely and continue to use the
get/set functions directly without making their code ugly.
I also like getThing and setThing more than get_thing and set_thing for
defining a property called "thing". They both have problems, though:
the former can't define a property starting with an uppercase letter,
Well, yes and no. You could map both the property "thing" and "Thing"
to "setThing"/"getThing", thus making the first character of a property
case-insensitive. That's a little awkward, though. But that's exactly
what key-value coding does for getting and setting value in Objective-C
[1].
[1]:
http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/Compliant.html
and
the latter can't define a property starting with an underscore.
(Symbols can't contain two underscores.) Ideas?
This has been shown to not be the case by Jarret. So set_thing and
get_thing can work indeed.
I don't like that underscore much though: it looks like a special
syntax for properties that goes against the language style guidelines.
Sure you can change the style guidelines to adopt them, but this syntax
will still look out of place.
Here's an example:
~~~
int getValue();
void setValue(int x);
setValue(1); /* property: */ value = 1;
assert(getValue() == 1); /* property: */ assert(value == 1);
~~~
The problems this syntax should fix are:
1. the ambiguity between actions and properties: getValue()/setValue()
are functions and thus actions named with verbs ("get" and "set"), but
you can access them as the "value" property too, which is a noun that
will call the function as necessary when an action is needed. (As a
bonus, this makes "writeln = 2" illegal.)
Cool. If I only defined getEmpty, to I get to still use empty?
Exactly. You define "bool getEmpty()" and the compiler rewrites any
call to a property "empty" as "getEmpty()".
2. the inconsistency for functions and properties returning something
such as a delegate or a struct or class with an opCall member, where
you absolutely need to write the function with a parenthesis to
actually call the returned value. You can either call the function
"getMyDelegate()(delegate_arg)" or use the property
"myDelegate(delegate_arg)" just as you can with a field.
Very nice solution indeed.
This syntax doesn't solve the operator overloading issue. It isn't
meant to do that either: properties should stay simple.
Which issue are you referring to? +=?
This, and any other operator of this kind (++, --, *=, etc.).
The two small problems it pose are:
1. There's an ambiguity when another symbol is named after the property
name that would call the get/set function. I suggest that this other
symbol simply hide the property.
I wonder what should happen when this happens across scopes, e.g. in
base and derived classes.
And I wonder more what happens with the various protection attributes.
Re: YAPP - D properties - voting
aarti_pl, el 1 de agosto a las 16:44 me escribiste: > Ok. Let's do some voting. > > I extended pool with latest syntax suggestion. I also added additional pool > about omissible parenthesis feature. > > Here is the link: > > http://www.igsoft.net/dpolls/index.php > > Let's vote and please do not kill my server ;-) This is getting ridiculous, we have as many property proposals as voting systems now... OMFG! -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) Sé que tu me miras, pero yo me juraría que, en esos ojos negros que tenés, hay un indio sensible que piensa: "Qué bárbaro que este tipo blanco esté tratando de comunicarse conmigo que soy un ser inferior en la escala del homo sapiens". Por eso, querido indio, no puedo dejar de mirarte como si fueras un cobayo de mierda al que puedo pisar cuando quiera. -- Ricardo Vaporeso. Carta a los aborígenes, ed. Gredos, Barcelona, 1912, página 102.
Re: True Properties Poll
Jesse Phillips, el 31 de julio a las 15:11 me escribiste: > It seem no one is confident in their poll writing skills, so I'll take stab > at it. > > This poll is related to D not providing "true" properties. Details and > discussion can be found in DIP4: > http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4 > > Below you will find a list of options. Please place a maximum of three votes > starting with what you would prefer and then your alternatives. Reasoning can > come after your vote. > > 1. Provide a special syntax/keyword to specify properties. > 2. Keep things as they are. > 3. Keep things as they are, resolving the += ... without involving new > property syntax. > 4. Remove current "property" syntax. > 5. Prevent . on rvalues 1 3 5 > Extended Voting > > A. #4 should happen with or without a new property syntax. > B. Preventing . on rvalues should be done anyway. B -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) - Que hacés, ratita? - Espero un ratito...
Re: Omissible Parentheses...
On Sat, 01 Aug 2009 21:04:43 +0400, Chad J wrote: Omissible Parentheses Could someone remind me why we don't remove these? So far I have - They save typing. - Removing them breaks backwards compatibility. - They allow some features of properties, but with a list of limitations and gotchas. This is not intended to be a deep discussion. I'm writing a piece on properties, so I'm gathering information. Andrei likes them.
Omissible Parentheses...
Omissible Parentheses Could someone remind me why we don't remove these? So far I have - They save typing. - Removing them breaks backwards compatibility. - They allow some features of properties, but with a list of limitations and gotchas. This is not intended to be a deep discussion. I'm writing a piece on properties, so I'm gathering information.
Re: property / getProperty() / setProperty()
"Andrei Alexandrescu" wrote in message news:h51rnq$o2...@digitalmars.com... > Jarrett Billingsley wrote: >> I'll ask again: do you have any *technical* issues with the 'property' >> attribute suggestion? > > My main technical issue is throwing a keyword at a very minor issue. Yeah, it is pretty minor, huh? I mean, it's not like it's been the center of discussion for the past week. And no one has ever complained about it before. Downplaying the size of the issue at hand doesn't make it go away. > Once the keyword is in the mix, we need to define how it interacts with > everything else (e.g., are properties overridable?) Of course they're overridable. They are *functions*. They do everything exactly the same as other functions. *All* the property attribute would do is enforce a property syntax at the use site instead of a function call syntax. > A solution based on rewrites is considerably simpler and more in according > with the size of the problem. A solution based on rewrites has a pretty horrible problem with name ambiguity. And this isn't even a technical concern; you're just saying again that the problem is minor. You have not presented any technical arguments against the property attribute suggestion. So let me get this straight: the property attribute would be better technically, but let's not throw more keywords at it; so instead we suggest attributes, but no, they don't have any useful purpose. WHAT.
Re: property / getProperty() / setProperty()
Andrei Alexandrescu escribió: Jarrett Billingsley wrote: On Sat, Aug 1, 2009 at 12:21 PM, Andrei Alexandrescu wrote: bearophile wrote: Andrei Alexandrescu: Thanks. So it looks like get_property() and set_property() could fly. How does that sound? Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly. We can't throw keywords at problems like they're getting out of style. I've noticed that here every little problem gets solved by a little keyword. If not, some arcane new syntax. Nobody seems to care about rewriting, which I think is best. I don't know if you're just being passive-aggressive here or what. Is this a response to my post? I'll ask again: do you have any *technical* issues with the 'property' attribute suggestion? My main technical issue is throwing a keyword at a very minor issue. Once the keyword is in the mix, we need to define how it interacts with everything else (e.g., are properties overridable?) A solution based on rewrites is considerably simpler and more in according with the size of the problem. The "property" just signals that the function is a property. But it's still a function and all of the previous rules that existed are still valid. I'll copy Jarrett's points here once more: 1. You can no longer call functions as properties that were never intended to be (writeln = 4; goes away). 2. The "obj.prop(args)" ambiguity goes away. *Either* obj.prop is a normal method function and (args) are passed to it, *or* obj.prop has the "property" attribute, and (args) are passed to its result. Stuff like "obj.prop[i]" is the same way. 3. There is no naming ambiguity. 4. There are no case issues. 5. It provides useful semantic information to tools, IDEs, and reflection. 6. It's nonintrusive and self-documenting. As you can see, the only thing that will change for users is point 1. Nothing else changes, no need to define new rules, new syntax, new nothing. It's as unobstrusive as possible (obviusly much better if attributes were already present in the language). About attributes, later I'll write a post about how attribute can be started to be implemented (not just the syntax, but what the compiler does with them).
Re: property / getProperty() / setProperty()
Ary Borenszweig wrote: Andrei Alexandrescu escribió: bearophile wrote: Andrei Alexandrescu: Thanks. So it looks like get_property() and set_property() could fly. How does that sound? Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly. We can't throw keywords at problems like they're getting out of style. I've noticed that here every little problem gets solved by a little keyword. If not, some arcane new syntax. Nobody seems to care about rewriting, which I think is best. So what do you think about introducing attributes? Not only it will help not introducing new keyword, but it'll also *reduce* the amount of keywords that exist right now. Attributes would be great, but you guys should stop asking me what I think and ask Walter. I seem to vaguely recall Walter isn't very excited about attributes. Andrei
Re: property / getProperty() / setProperty()
Jarrett Billingsley wrote: On Sat, Aug 1, 2009 at 12:21 PM, Andrei Alexandrescu wrote: bearophile wrote: Andrei Alexandrescu: Thanks. So it looks like get_property() and set_property() could fly. How does that sound? Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly. We can't throw keywords at problems like they're getting out of style. I've noticed that here every little problem gets solved by a little keyword. If not, some arcane new syntax. Nobody seems to care about rewriting, which I think is best. I don't know if you're just being passive-aggressive here or what. Is this a response to my post? I'll ask again: do you have any *technical* issues with the 'property' attribute suggestion? My main technical issue is throwing a keyword at a very minor issue. Once the keyword is in the mix, we need to define how it interacts with everything else (e.g., are properties overridable?) A solution based on rewrites is considerably simpler and more in according with the size of the problem. Andrei
Re: YAPP - yet another properties poll
aarti_pl wrote: > [2],[3],[4] Choosing one of possible options will give you answer what > is preferred. Also introducing new syntax without removing ommitable > parenthesis feature doesn't make much sense, as it cause than there is > no real difference between function and property. Just wanted to point out that yes, it does make sense. I don't agree with it, but it makes sense. Once properties are added the omissible parens can maybe save some typing on function calls, or whatever their advantages are (to be honest I forget why they are useful). It would be impossible to define a function and property of the same name, so no ambiguities would arise.
Re: property / getProperty() / setProperty()
On Sat, Aug 1, 2009 at 12:21 PM, Andrei Alexandrescu wrote: > bearophile wrote: >> >> Andrei Alexandrescu: >>> >>> Thanks. So it looks like get_property() and set_property() could fly. How >>> does that sound? >> >> Not too much good. Among the simpler solutions there's the 'property' >> attribute, that while not helping in reducing code (it makes code longer!) >> solves most problems, while being simple. It's the minimal solution that I >> think will work/fly. > > We can't throw keywords at problems like they're getting out of style. I've > noticed that here every little problem gets solved by a little keyword. If > not, some arcane new syntax. Nobody seems to care about rewriting, which I > think is best. I don't know if you're just being passive-aggressive here or what. Is this a response to my post? I'll ask again: do you have any *technical* issues with the 'property' attribute suggestion?
Re: property / getProperty() / setProperty()
Andrei Alexandrescu escribió: bearophile wrote: Andrei Alexandrescu: Thanks. So it looks like get_property() and set_property() could fly. How does that sound? Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly. We can't throw keywords at problems like they're getting out of style. I've noticed that here every little problem gets solved by a little keyword. If not, some arcane new syntax. Nobody seems to care about rewriting, which I think is best. So what do you think about introducing attributes? Not only it will help not introducing new keyword, but it'll also *reduce* the amount of keywords that exist right now.
Re: True Properties Poll
On Fri, 31 Jul 2009 23:11:41 +0400, Jesse Phillips wrote: It seem no one is confident in their poll writing skills, so I'll take stab at it. This poll is related to D not providing "true" properties. Details and discussion can be found in DIP4: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP4 Below you will find a list of options. Please place a maximum of three votes starting with what you would prefer and then your alternatives. Reasoning can come after your vote. 1. Provide a special syntax/keyword to specify properties. 2. Keep things as they are. 3. Keep things as they are, resolving the += ... without involving new property syntax. 4. Remove current "property" syntax. 5. Prevent . on rvalues 1, 3, 4 Extended Voting A. #4 should happen with or without a new property syntax. B. Preventing . on rvalues should be done anyway. If I missed something, to bad, write your own poll. Please only respond if you are voting or commenting on another's vote. This allows top level posts to contain poll answers only.
Re: property / getProperty() / setProperty()
On Sat, Aug 1, 2009 at 12:21 PM, Robert Jacques wrote:
> On Sat, 01 Aug 2009 11:56:23 -0400, Jarrett Billingsley
> wrote:
>>
>> 1. You can no longer call functions as properties that were never
>> intended to be (writeln = 4; goes away).
>
> *sigh* writeln = 4 doesn't compile and hasn't for a while. It would be nice
> if the examples were valid code.
I'm a D1 user. It compiles in D1, because writeln (or writefln) is
defined as a normal non-templated function.
Here, have this instead:
void foo(int){}
foo = 5;
Re: OS X Installer
Michel Fortin wrote: You can use /opt/dmd and /opt/dmd2, if you don't want to use the regular file hierarchy in hier(7) In hier(7), it says that "/usr/local" is for "executables, libraries, etc. not included by the basic operating system", so I guess DMD fits this quite well. I normally* use the regular /usr/local/bin and /usr/local/lib and so on, when using /usr/local and otherwise /opt for various vendor layouts... But I suppose /usr/local/dmd "works" just fine. Renaming dmd to dmd1 probably makes sense, once dmd2 is released, and switching with the symlink. Was using something similar to switch between the Phobos and Tango libraries in earlier versions. --anders * GDC was using /usr/bin, since it was sharing some files with /usr/bin/gcc already anyway.
Re: property / getProperty() / setProperty()
On Sat, 01 Aug 2009 11:56:23 -0400, Jarrett Billingsley wrote: 1. You can no longer call functions as properties that were never intended to be (writeln = 4; goes away). *sigh* writeln = 4 doesn't compile and hasn't for a while. It would be nice if the examples were valid code.
Re: property / getProperty() / setProperty()
bearophile wrote: Andrei Alexandrescu: Thanks. So it looks like get_property() and set_property() could fly. How does that sound? Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly. We can't throw keywords at problems like they're getting out of style. I've noticed that here every little problem gets solved by a little keyword. If not, some arcane new syntax. Nobody seems to care about rewriting, which I think is best. Andrei
Re: property / getProperty() / setProperty()
Jarrett Billingsley Wrote:
> On Sat, Aug 1, 2009 at 10:14 AM, Michel Fortin
> wrote:
>
> > The best simple solution to that property problem I've seen up to now is to
> > define "getProperty" and "setProperty" and have the compiler automatically
> > check for these functions when it encounters the "property" symbol.
> >
> > Why do I favor "getThing" and "setThing" over "opGet_thing" and
> > "opSet_thing"? Because the later are ugly. Please don't underestimate
> > aestetics and readability as those are the key to make the language
> > enjoyable to use and what the beginners will judge the language from. Also,
> > the pattern will be pretty familiar to those comming from Java and
> > elsewhere. And finally, for those who don't like having a property syntax,
> > they can ignore properties completely and continue to use the get/set
> > functions directly without making their code ugly.
> >
> > Here's an example:
> >
> > ~~~
> > int getValue();
> > void setValue(int x);
> >
> > setValue(1); /* property: */ value = 1;
> > assert(getValue() == 1); /* property: */ assert(value == 1);
> > ~~~
> >
> > The problems this syntax should fix are:
> >
> > 1. the ambiguity between actions and properties: getValue()/setValue() are
> > functions and thus actions named with verbs ("get" and "set"), but you can
> > access them as the "value" property too, which is a noun that will call the
> > function as necessary when an action is needed. (As a bonus, this makes
> > "writeln = 2" illegal.)
> >
> > 2. the inconsistency for functions and properties returning something such
> > as a delegate or a struct or class with an opCall member, where you
> > absolutely need to write the function with a parenthesis to actually call
> > the returned value. You can either call the function
> > "getMyDelegate()(delegate_arg)" or use the property
> > "myDelegate(delegate_arg)" just as you can with a field.
> >
> > This syntax doesn't solve the operator overloading issue. It isn't meant to
> > do that either: properties should stay simple.
> >
> > The two small problems it pose are:
> >
> > 1. There's an ambiguity when another symbol is named after the property name
> > that would call the get/set function. I suggest that this other symbol
> > simply hide the property.
> >
> > 2. You need an uppercase algorithm in the compiler to be able to translate
> > "property" to "setProperty" and "getProperty" and do the proper lookup. This
> > works well for ASCII, but can it go messy with Unicode?
> >
> > To avoid converting to unicode upercase, we could use "get_thing" and
> > "set_thing" (nicer than opGet/opSet), although that doesn't really fit with
> > the coding standards of D.
>
> It's been mentioned before, and I'll mention it again: a simple
> 'property' attribute that can be applied to any function. No new
> syntax, no get/set/value 'magic' keywords, just 'property.' Applying
> it to a function makes the compiler enforce the property syntax when
> using the functions. Any function that doesn't have the property
> attribute - which should be most functions - can't be treated as one.
> It doesn't require any special support from the compiler beyond what
> it currently does. It doesn't require any 'magic'. It doesn't
> require any verbose syntax. It solves pretty much all the problems.
>
> 1. You can no longer call functions as properties that were never
> intended to be (writeln = 4; goes away).
> 2. The "obj.prop(args)" ambiguity goes away. *Either* obj.prop is a
> normal method function and (args) are passed to it, *or* obj.prop has
> the "property" attribute, and (args) are passed to its result. Stuff
> like "obj.prop[i]" is the same way.
> 3. There is no naming ambiguity.
> 4. There are no case issues.
> 5. It provides useful semantic information to tools, IDEs, and reflection.
> 6. It's nonintrusive and self-documenting.
>
This gets my vote. Clean, elegant, works well, looks good.
Re: new DIP5: Properties 2
Bill Baxter wrote: On Fri, Jul 31, 2009 at 9:13 AM, Andrei Alexandrescu wrote: Sergey Gromov wrote: Fri, 31 Jul 2009 00:02:16 -0400, Benji Smith wrote: Nick Sabalausky wrote: "Andrei Alexandrescu" wrote in message news:h4lsuo$au...@digitalmars.com... For me, I get a breath of fresh air whenever I get to not write "()". I can't figure how some are missing it. Every time I call a parameterless function in D, I curse under my breath at how incredibly sloppy it is. Great, just what I need: Yet another thing that forces me to make the completely unnecessary choice between using something inconsistently or making up and sticking to a completely arbitrary convention that can't be enforced. Sloppy, sloppy, sloppy. Especially considering it's all for the sake of a "feature" that doesn't accomplish a damn thing, doesn't solve any problem, not even a trivial one, doesn't do anything but clutter the language. My thoughts exactly. +1 Maybe we should vote on this too. BTW, seems like the last poll wasn't quite the expected landslide against the dictature :o). I was on vacation the last two days so I didn't see any of these polls till today. But the poll I did see was like 8 to 5 in favor of a change. It doesn't really seem like a statistically significant sample. Seems like the "I don't care enough" vote is the vast majority there. Assuming D has significantly more than 13 users, that is. Or perhaps it's the "you guys have gone on about this for far too long and and I now have no idea what this is about anymore" vote. I've seen a vote in which more than 50 voted. Still doesn't say anything statistically significant, but it's more than a handful. Andrei
Re: new DIP5: Properties 2
On Fri, Jul 31, 2009 at 9:13 AM, Andrei Alexandrescu wrote: > Sergey Gromov wrote: >> >> Fri, 31 Jul 2009 00:02:16 -0400, Benji Smith wrote: >> >>> Nick Sabalausky wrote: "Andrei Alexandrescu" wrote in message news:h4lsuo$au...@digitalmars.com... > > For me, I get a breath of fresh air whenever I get to not write "()". I > can't figure how some are missing it. > Every time I call a parameterless function in D, I curse under my breath at how incredibly sloppy it is. Great, just what I need: Yet another thing that forces me to make the completely unnecessary choice between using something inconsistently or making up and sticking to a completely arbitrary convention that can't be enforced. Sloppy, sloppy, sloppy. Especially considering it's all for the sake of a "feature" that doesn't accomplish a damn thing, doesn't solve any problem, not even a trivial one, doesn't do anything but clutter the language. >>> >>> My thoughts exactly. >> >> +1 > > Maybe we should vote on this too. BTW, seems like the last poll wasn't quite > the expected landslide against the dictature :o). I was on vacation the last two days so I didn't see any of these polls till today. But the poll I did see was like 8 to 5 in favor of a change. It doesn't really seem like a statistically significant sample. Seems like the "I don't care enough" vote is the vast majority there. Assuming D has significantly more than 13 users, that is. Or perhaps it's the "you guys have gone on about this for far too long and and I now have no idea what this is about anymore" vote. --bb
Re: property / getProperty() / setProperty()
Andrei Alexandrescu: > Thanks. So it looks like get_property() and set_property() could fly. > How does that sound? Not too much good. Among the simpler solutions there's the 'property' attribute, that while not helping in reducing code (it makes code longer!) solves most problems, while being simple. It's the minimal solution that I think will work/fly. There are also other alternative (and a little more complex) solutions (inspired by C# too), that allow to reduce boilerplate code. I have asked for one of them more than one year ago. They aren't hard to learn. Bye, bearophile
Re: new DIP5: Properties 2
On Fri, Jul 31, 2009 at 10:09 PM, Andrei Alexandrescu wrote: > Benji Smith wrote: >> >> Andrei Alexandrescu wrote: >>> >>> Steven Schveighoffer wrote: So to sum up, with this feature lack of parentheses would imply no action, but would not be enforced. However, it would be considered incorrect logic if the rule was not followed, similar to naming your functions something other than what they do. >>> >>> I am leery of such a feature. It essentially introduces a way to define >>> conventions that are in no way useful to, or checked by, language rules. In >>> my experience this has been a bad idea more often than not. >> >> Like it or not, that's exactly the situation we have now, with the >> (sometimes)-optional parentheses. Some people are using a convention of >> never using the optional parens. Other people use the parens only when a >> function an action, and avoiding them otherwise. And some other people (like >> me) always use the parens. >> >> So the clusterfuck of unenforceable and useless conventions is already >> here. Here's my suggestions: if you think putting parentheses on a no-arg >> function is stupid, then it should be a syntax error for them to exist. That >> wouldn't be my first choice, but it'd be a thousand times better than the >> situation with optional parens. >> >> --benji > > I agree that it's not good to have two ways of doing the same thing. Now > think of it for a second: a full-blown language feature has been proposed to > not fix that, but reify it. Not quite right. We *already* have a language feature that reifies it. The proposal is to adjust that feature to *remove* the arbitrary choice from the caller and give the choice to the API designer, which is a much more sensible place for it to reside. The logical conclusion if you stick by that argument is that we should remove the optional () rule and go back to the simpler C/C++ rule. --bb
Re: property / getProperty() / setProperty()
On Sat, Aug 1, 2009 at 11:54 AM, Andrei Alexandrescu wrote: > Jarrett Billingsley wrote: >> >> On Sat, Aug 1, 2009 at 11:42 AM, Jarrett >> Billingsley wrote: >>> >>> On Sat, Aug 1, 2009 at 11:31 AM, Andrei >>> Alexandrescu wrote: >>> > To avoid converting to unicode upercase, we could use "get_thing" and > "set_thing" (nicer than opGet/opSet), although that doesn't really fit > with > the coding standards of D. Also, again, if you want to define "_thing" you'd have to write "get__thing" and "set__thing". Maybe we could lift the restriction about two underscores and only keep it for two leading underscores. >>> >>> I'm pretty sure that's what the restriction is now (no leading double >>> underscores). I don't think a__b is reserved. >>> >> >> It is. >> "Identifiers starting with __ (two underscores) are reserved." > > Thanks. So it looks like get_property() and set_property() could fly. How > does that sound? See my other reply.
Re: property / getProperty() / setProperty()
On Sat, Aug 1, 2009 at 10:14 AM, Michel Fortin wrote:
> The best simple solution to that property problem I've seen up to now is to
> define "getProperty" and "setProperty" and have the compiler automatically
> check for these functions when it encounters the "property" symbol.
>
> Why do I favor "getThing" and "setThing" over "opGet_thing" and
> "opSet_thing"? Because the later are ugly. Please don't underestimate
> aestetics and readability as those are the key to make the language
> enjoyable to use and what the beginners will judge the language from. Also,
> the pattern will be pretty familiar to those comming from Java and
> elsewhere. And finally, for those who don't like having a property syntax,
> they can ignore properties completely and continue to use the get/set
> functions directly without making their code ugly.
>
> Here's an example:
>
> ~~~
> int getValue();
> void setValue(int x);
>
> setValue(1); /* property: */ value = 1;
> assert(getValue() == 1); /* property: */ assert(value == 1);
> ~~~
>
> The problems this syntax should fix are:
>
> 1. the ambiguity between actions and properties: getValue()/setValue() are
> functions and thus actions named with verbs ("get" and "set"), but you can
> access them as the "value" property too, which is a noun that will call the
> function as necessary when an action is needed. (As a bonus, this makes
> "writeln = 2" illegal.)
>
> 2. the inconsistency for functions and properties returning something such
> as a delegate or a struct or class with an opCall member, where you
> absolutely need to write the function with a parenthesis to actually call
> the returned value. You can either call the function
> "getMyDelegate()(delegate_arg)" or use the property
> "myDelegate(delegate_arg)" just as you can with a field.
>
> This syntax doesn't solve the operator overloading issue. It isn't meant to
> do that either: properties should stay simple.
>
> The two small problems it pose are:
>
> 1. There's an ambiguity when another symbol is named after the property name
> that would call the get/set function. I suggest that this other symbol
> simply hide the property.
>
> 2. You need an uppercase algorithm in the compiler to be able to translate
> "property" to "setProperty" and "getProperty" and do the proper lookup. This
> works well for ASCII, but can it go messy with Unicode?
>
> To avoid converting to unicode upercase, we could use "get_thing" and
> "set_thing" (nicer than opGet/opSet), although that doesn't really fit with
> the coding standards of D.
It's been mentioned before, and I'll mention it again: a simple
'property' attribute that can be applied to any function. No new
syntax, no get/set/value 'magic' keywords, just 'property.' Applying
it to a function makes the compiler enforce the property syntax when
using the functions. Any function that doesn't have the property
attribute - which should be most functions - can't be treated as one.
It doesn't require any special support from the compiler beyond what
it currently does. It doesn't require any 'magic'. It doesn't
require any verbose syntax. It solves pretty much all the problems.
1. You can no longer call functions as properties that were never
intended to be (writeln = 4; goes away).
2. The "obj.prop(args)" ambiguity goes away. *Either* obj.prop is a
normal method function and (args) are passed to it, *or* obj.prop has
the "property" attribute, and (args) are passed to its result. Stuff
like "obj.prop[i]" is the same way.
3. There is no naming ambiguity.
4. There are no case issues.
5. It provides useful semantic information to tools, IDEs, and reflection.
6. It's nonintrusive and self-documenting.
The *only* technical issue I can come up with is if you had "property
ref X foo()", where foo returned a reference to some value type. Then
you do "&obj.foo" - what does this get the address of? To that end, I
suggest that &obj.foo always gets the address of the member or method
'foo' from object 'obj', and &(obj.foo) would get the address of the
return value of obj.foo. The extra parens in there say "really, I
want you to evaluate the thing inside *first*".
Andrei, I don't know your thoughts on this. I know you don't like the
idea of introducing new syntax but this is really as minimalistic as
you can get. Do you have any technical issues with this proposal? Is
there a reason why you would choose the opGet_foo/get_foo proposal
over this?
Re: property / getProperty() / setProperty()
Jarrett Billingsley wrote: On Sat, Aug 1, 2009 at 11:42 AM, Jarrett Billingsley wrote: On Sat, Aug 1, 2009 at 11:31 AM, Andrei Alexandrescu wrote: To avoid converting to unicode upercase, we could use "get_thing" and "set_thing" (nicer than opGet/opSet), although that doesn't really fit with the coding standards of D. Also, again, if you want to define "_thing" you'd have to write "get__thing" and "set__thing". Maybe we could lift the restriction about two underscores and only keep it for two leading underscores. I'm pretty sure that's what the restriction is now (no leading double underscores). I don't think a__b is reserved. It is. "Identifiers starting with __ (two underscores) are reserved." Thanks. So it looks like get_property() and set_property() could fly. How does that sound? Andrei
Re: property / getProperty() / setProperty()
On Sat, Aug 1, 2009 at 11:42 AM, Jarrett Billingsley wrote: > On Sat, Aug 1, 2009 at 11:31 AM, Andrei > Alexandrescu wrote: > >>> To avoid converting to unicode upercase, we could use "get_thing" and >>> "set_thing" (nicer than opGet/opSet), although that doesn't really fit with >>> the coding standards of D. >> >> Also, again, if you want to define "_thing" you'd have to write "get__thing" >> and "set__thing". Maybe we could lift the restriction about two underscores >> and only keep it for two leading underscores. > > I'm pretty sure that's what the restriction is now (no leading double > underscores). I don't think a__b is reserved. > It is. "Identifiers starting with __ (two underscores) are reserved."
Re: property / getProperty() / setProperty()
On Sat, Aug 1, 2009 at 11:31 AM, Andrei Alexandrescu wrote: >> To avoid converting to unicode upercase, we could use "get_thing" and >> "set_thing" (nicer than opGet/opSet), although that doesn't really fit with >> the coding standards of D. > > Also, again, if you want to define "_thing" you'd have to write "get__thing" > and "set__thing". Maybe we could lift the restriction about two underscores > and only keep it for two leading underscores. I'm pretty sure that's what the restriction is now (no leading double underscores). I don't think a__b is reserved.
Re: property / getProperty() / setProperty()
Michel Fortin wrote:
I hope this proposal can rally more that divide... let's see.
Andrei said this in another thread about adding a property keyword in
front of functions to make them properties:
The problem is that it's all loss, no gain: the callee must make the
decision whether the call must be with or without parens, and the caller
must obey that decision. There is no guarantee gained, only effort.
I see your point Andrei: it's little gain to add a syntax that's just a
modifier to a function to decide how you must call it.
That's a great summary.
I also see the point of all those arguing that it's important to be able
to distinguish between a property and an action, and that the english
laguage is not expressive enough to make that distinction clear in a lot
of cases.
I understand that point too.
I know, I've written programming guidelines[1] and tried very
hard to make this problem go away by mandating "is", "has" or a modal
verb as a prefix for boolean attributes in the guidelines, only to be
stuck with no solution for the "transform" example from Bill Baxter
(thread "Properties - another one that gets me") which isn't boolean and
for which you can't really add a prefix that makes sense.
[1]: http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines
Good point.
The best simple solution to that property problem I've seen up to now is
to define "getProperty" and "setProperty" and have the compiler
automatically check for these functions when it encounters the
"property" symbol.
Why do I favor "getThing" and "setThing" over "opGet_thing" and
"opSet_thing"? Because the later are ugly. Please don't underestimate
aestetics and readability as those are the key to make the language
enjoyable to use and what the beginners will judge the language from.
Also, the pattern will be pretty familiar to those comming from Java and
elsewhere. And finally, for those who don't like having a property
syntax, they can ignore properties completely and continue to use the
get/set functions directly without making their code ugly.
I also like getThing and setThing more than get_thing and set_thing for
defining a property called "thing". They both have problems, though: the
former can't define a property starting with an uppercase letter, and
the latter can't define a property starting with an underscore. (Symbols
can't contain two underscores.) Ideas?
Here's an example:
~~~
int getValue();
void setValue(int x);
setValue(1); /* property: */ value = 1;
assert(getValue() == 1); /* property: */ assert(value == 1);
~~~
The problems this syntax should fix are:
1. the ambiguity between actions and properties: getValue()/setValue()
are functions and thus actions named with verbs ("get" and "set"), but
you can access them as the "value" property too, which is a noun that
will call the function as necessary when an action is needed. (As a
bonus, this makes "writeln = 2" illegal.)
Cool. If I only defined getEmpty, to I get to still use empty?
2. the inconsistency for functions and properties returning something
such as a delegate or a struct or class with an opCall member, where you
absolutely need to write the function with a parenthesis to actually
call the returned value. You can either call the function
"getMyDelegate()(delegate_arg)" or use the property
"myDelegate(delegate_arg)" just as you can with a field.
Very nice solution indeed.
This syntax doesn't solve the operator overloading issue. It isn't meant
to do that either: properties should stay simple.
Which issue are you referring to? +=?
The two small problems it pose are:
1. There's an ambiguity when another symbol is named after the property
name that would call the get/set function. I suggest that this other
symbol simply hide the property.
I wonder what should happen when this happens across scopes, e.g. in
base and derived classes.
2. You need an uppercase algorithm in the compiler to be able to
translate "property" to "setProperty" and "getProperty" and do the
proper lookup. This works well for ASCII, but can it go messy with Unicode?
Good question.
To avoid converting to unicode upercase, we could use "get_thing" and
"set_thing" (nicer than opGet/opSet), although that doesn't really fit
with the coding standards of D.
Also, again, if you want to define "_thing" you'd have to write
"get__thing" and "set__thing". Maybe we could lift the restriction about
two underscores and only keep it for two leading underscores.
Andrei
Re: new DIP5: Properties 2
Ary Borenszweig: >But, man, am I so excited to be able to overload my functions and templated >functions!< The "support for fast and reliable build tools to the frontend" is a first step of one of the things people have asked for for a lot of time, so once in a while Walter listens to people, so it's not wise to stop asking things. Recently we have written a list of things to be done before D2 comes out of alpha state (and the top of the wish list there are Stack tracing and Reflection API). Overloading functions & templates was not asked by anyone. There are some things in the design of D1/D2 that aren't that useful, while there are some things that are quite useful but absent. The only way to remove the things that aren't much useful is to break backwards compatibility, this is hard to do in a language that's already in beta stage. I suggest Walter to write some real program using D1, programs that future D programmers may really want to write, for example using Descent. This may show him some of the things people ask for and why they ask for them. Also taking a look at C# and Scala will help (they aren't perfect, but they are modern and C# is designed for quite practical purposes). Bye, bearophile
Re: new DIP5: Properties 2
Steven Schveighoffer wrote: On Sat, 01 Aug 2009 01:04:49 -0400, Andrei Alexandrescu wrote: What you need in order to be convincing are better arguments From the responses from everyone else in this newsgroup, I think you may be alone in that opinion. http://poll.pollcode.com/Iy0_result?v Andrei
YAPP - D properties - voting
Ok. Let's do some voting. I extended pool with latest syntax suggestion. I also added additional pool about omissible parenthesis feature. Here is the link: http://www.igsoft.net/dpolls/index.php Let's vote and please do not kill my server ;-) BR Marcin Kuszczak (aarti_pl)
property / getProperty() / setProperty()
I hope this proposal can rally more that divide... let's see.
Andrei said this in another thread about adding a property keyword in
front of functions to make them properties:
The problem is that it's all loss, no gain: the callee must make the
decision whether the call must be with or without parens, and the caller
must obey that decision. There is no guarantee gained, only effort.
I see your point Andrei: it's little gain to add a syntax that's just a
modifier to a function to decide how you must call it.
I also see the point of all those arguing that it's important to be
able to distinguish between a property and an action, and that the
english laguage is not expressive enough to make that distinction clear
in a lot of cases. I know, I've written programming guidelines[1] and
tried very hard to make this problem go away by mandating "is", "has"
or a modal verb as a prefix for boolean attributes in the guidelines,
only to be stuck with no solution for the "transform" example from Bill
Baxter (thread "Properties - another one that gets me") which isn't
boolean and for which you can't really add a prefix that makes sense.
[1]: http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines
The best simple solution to that property problem I've seen up to now
is to define "getProperty" and "setProperty" and have the compiler
automatically check for these functions when it encounters the
"property" symbol.
Why do I favor "getThing" and "setThing" over "opGet_thing" and
"opSet_thing"? Because the later are ugly. Please don't underestimate
aestetics and readability as those are the key to make the language
enjoyable to use and what the beginners will judge the language from.
Also, the pattern will be pretty familiar to those comming from Java
and elsewhere. And finally, for those who don't like having a property
syntax, they can ignore properties completely and continue to use the
get/set functions directly without making their code ugly.
Here's an example:
~~~
int getValue();
void setValue(int x);
setValue(1); /* property: */ value = 1;
assert(getValue() == 1); /* property: */ assert(value == 1);
~~~
The problems this syntax should fix are:
1. the ambiguity between actions and properties: getValue()/setValue()
are functions and thus actions named with verbs ("get" and "set"), but
you can access them as the "value" property too, which is a noun that
will call the function as necessary when an action is needed. (As a
bonus, this makes "writeln = 2" illegal.)
2. the inconsistency for functions and properties returning something
such as a delegate or a struct or class with an opCall member, where
you absolutely need to write the function with a parenthesis to
actually call the returned value. You can either call the function
"getMyDelegate()(delegate_arg)" or use the property
"myDelegate(delegate_arg)" just as you can with a field.
This syntax doesn't solve the operator overloading issue. It isn't
meant to do that either: properties should stay simple.
The two small problems it pose are:
1. There's an ambiguity when another symbol is named after the property
name that would call the get/set function. I suggest that this other
symbol simply hide the property.
2. You need an uppercase algorithm in the compiler to be able to
translate "property" to "setProperty" and "getProperty" and do the
proper lookup. This works well for ASCII, but can it go messy with
Unicode?
To avoid converting to unicode upercase, we could use "get_thing" and
"set_thing" (nicer than opGet/opSet), although that doesn't really fit
with the coding standards of D.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: new DIP5: Properties 2
Steven Schveighoffer escribió: On Sat, 01 Aug 2009 01:04:49 -0400, Andrei Alexandrescu wrote: What you need in order to be convincing are better arguments From the responses from everyone else in this newsgroup, I think you may be alone in that opinion. I agree. And I also think it's now worthless to continue discussing this. Properties won't get implemented in any of the ways discussed in the newsgroup. But, man, am I so excited to be able to overload my functions and templated functions!
Re: The XML module in Phobos
On 2009-08-01 00:04:01 -0400, Benji Smith said: But XML documents aren't really lists. They're trees. Do ranges provide an abstraction for working with trees (other than the obvious flattening algorithms, like breadth-first or depth-first traversal)? Well, it depends at what level you look. An XML document you read is first a list of bytes, then a list of Unicode characters, then you convert those characters to a list of tokens -- the Tango pull-parser sees each tag and each attribute as a token, SAX define each tag (including attributes) as a token and calls it an event -- and from that list of token you can construct a tree. The tree isn't a list though, and a range is a unidimentional list of something. You need another interface to work with the tree. But then, from the tree, create a list in one way or another (flattening, or performing an XPath query for instance) and then you can have a range representing the list of subtrees for the query if you want. That's pretty good since with a range you can lazily iterate over the results. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: new DIP5: Properties 2
On Sat, 01 Aug 2009 01:04:49 -0400, Andrei Alexandrescu wrote: What you need in order to be convincing are better arguments From the responses from everyone else in this newsgroup, I think you may be alone in that opinion. -Steve
Re: OS X Installer
On 2009-08-01 04:41:38 -0400, Anders F Björklund said:
Jacob Carlborg wrote:
Speaking of that OS X DMD installer, are you sure installing it at
/usr/share/dmd/ is a good idea? [...]
I looked at a gdc installer and looked where it placed the compiler and
did the same. I don't know where it's best to place the compiler.
You can use /opt/dmd and /opt/dmd2, if you don't
want to use the regular file hierarchy in hier(7)
DMD = /opt/dmd2/osx/bin/dmd
Or you can use e.g. /usr/local/bin and rename to
dmd2 and dmd2.conf (which takes some trickery...)
DMD = dmd2
In hier(7), it says that "/usr/local" is for "executables, libraries,
etc. not included by the basic operating system", so I guess DMD fits
this quite well.
I'm preparing an installer for D for Xcode and made it install DMD at
/usr/local/dmd and /usr/local/dmd2, with symlinks at /usr/local/bin/dmd
(system-prefered version) /usr/local/bin/dmd1 (1.x) and
/usr/local/bin/dmd2 (2.x). This makes it easy to choose the version you
want within Xcode.
For some reasons, the symlinks works fine with Xcode. But they aren't
working from the command line (dmd complains that it can't find
object.o). I've made a small C program to replace the symlink:
#include
int main(unsigned int argc, char **argv) {
argv[0] = "/usr/local/dmd/osx/bin/dmd";
execv("/usr/local/dmd/osx/bin/dmd", argv);
}
No more problem from the command line.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Compile time float binary representation
Jeremie Pelletier wrote: Is there a way to convert a float (or double/real) to an integral number without changing its binary representation at compile time? I need to extract the sign, exponent and mantissa yet I cant use bit shifting. "Error: 'R' is not of integral type, it is a real" is the error I get. There's a super-hacky way: pass the real as a template value parameter, and parse the .mangleof it! Not recommended, but it does work. The other way is to do it with CTFE, subtracting powers of 2 until the residual is < 1. Not great either. The usual *cast(uint*)&value wont work either at compile time. Any suggestions?
Re: YAPP - yet another properties poll
Chad J pisze: There is no mention of how the property implementation actually generates code. This is important, because the current implementation is syntax sugar, while my ideal is to have the compiler generate temporary values to ensure the property always works as expected. It is possible to have explicit property syntax yet not do this. I think that polls are only useful to get information about user preferences, not to solve complicated technical problems. Anyway I prefer solving problems "from general to detail". After pool we will know what are preferences about most visible part of this problem: syntax. Then it will be possible to go deeper into problem. (I assume here that presented syntaxes don't have grave problems, so they are equal in terms of technical solution.) "Keep things as they are, resolving existing problems (+=) without involving new property syntax" Is that even logically possible? The author of this viewpoint should at least point out how this can actually be done. Correct me if I am wrong, but I believe that Walter point of view is that problems with current properties can be solved just with some adjustments to current syntax? Anyway I am open for suggestions how this option should be formulated. I'm glad this moved away from some loosely related question like "what do you believe this means?" to the more important "what do you want?". It troubles me that anyone wanting to learn about this issue has to read through gigantic amounts of newsgroup discussion to be informed. The wiki's contents on this subject are somewhat inadequate. I still feel that some people who weren't involved in the lengthy discussions are somewhat uninformed, and it shows in the posts. This is too bad, since this voting should ideally hammer out differences in opinion rather than differences in commitment to newsgroup reading. At some point I'd like to compile all of the information I've learned about properties. It can then be reviewed/amended/corrected to represent known viewpoints. It's probably something I could pull off by the end of the weekend, though it would be an uncomfortable deadline. These are very true comments, but we can't do much about level of understanding among voters. That's why questions in poll should be easy to understand, so answer is possible without much pre-knowledge. Also note that things like the rvalue.member problem and omissible parentheses feature are orthogonal to properties. Yes, the omissible parentheses were added so as to behave like properties, but they are not the same thing as the "explicit" properties people talk about. It is entirely possible to maintain the current omissible parentheses while implementing an explicit property feature. Thus the options are not entirely exclusive to each other, rather they form a number of opinions. In conclusion, I suggest another format for voting: [1] Should D's rvalue.member syntax be forbidden? - yes - no - only assignment is forbidden, ex: "rvalue.member = foo;" [2] Should the omissible parentheses feature be removed? - yes - no [3] Should properties have an explicit syntax? - yes - no [4] (Only vote if you said yes to [3].) Which syntax do you prefer? - - - - etc... [5] Should the compiler to insert extra assignments and temporaries as needed to ensure setters are called when they appear on the left-hand-side of assignment expressions and next to unary operators? (Ex: "a.b.c = 3;" or "widget.rect.w = 100;" ) (Ex: "a.b++;" or "array.length++;" ) - Yes - No [6] Do you want existing property-related problems (such as "array.length++;") to be solved? - Yes - No Voting on any given issue is optional. For example: it is OK to vote on [1], [3], and [4], but not on [2], [5], and [6]. My objective in the above was to capture as many viewpoints that I've witnessed as possible. I may have missed some, which would be a shame, but is also almost inevitable. [6] is somewhat optional, but potentially enlightening when compared to the others. I like you proposed poll (and probably future polls should be more like above), but I think I will leave it as it is for now. Below my rationale: [1] I think this point needs some more description for pool (too difficult for uneducated voter to answer). [2],[3],[4] Choosing one of possible options will give you answer what is preferred. Also introducing new syntax without removing ommitable parenthesis feature doesn't make much sense, as it cause than there is no real difference between function and property. [5] Let's leave it for another pool :-) Maybe also too technical for pool. [6] It's also possible to get this information from proposed questions. (Not as clear - I agree) I would like to repeat: I really like your questions - they are simple and clear - when making pools it is the must. I adjusted questions, so they look currently as below: * Introduce syntax 1 (also remove ommitable parenthesis feature) * Introduce syntax
Re: OS X Installer
Jacob Carlborg wrote: Speaking of that OS X DMD installer, are you sure installing it at /usr/share/dmd/ is a good idea? [...] I looked at a gdc installer and looked where it placed the compiler and did the same. I don't know where it's best to place the compiler. You can use /opt/dmd and /opt/dmd2, if you don't want to use the regular file hierarchy in hier(7) DMD = /opt/dmd2/osx/bin/dmd Or you can use e.g. /usr/local/bin and rename to dmd2 and dmd2.conf (which takes some trickery...) DMD = dmd2 --anders
