Bill Baxter wrote:
> Hey Kirk if you're listening, what does PyD do with enums?

Currently nothing. Python has no obvious analogue, so enums are not currently a convertible type. Enums and structs are high on the list of things I need to support.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org

Miles wrote:
> Jordan Miner wrote:
>> Sometimes using the property syntax causes a compiler error:
> 
> Properties are also broken for cases like:
> 
> 	button.width -= 5;
> 	cursor.position++;
> 
> This is the essence of properties (it should be completely transparent
> for the user if it is accessing a variable or calling a method), yet D
> doesn't support it properly. This has the potential to break a lot of
> code when you convert variables into properties.

What is sad is that with the current property syntax, D can *never* achieve transparency. Even if ++a.x would be transformed into a.x(a.x()+1) there are cases that can never be transformed into an "accessor" property and make the accessing code remain the same. E.g:

struct Type {
	int delegate() prop;
}

Type t;

Used:
	t.prop()


Try transforming that into an accessor property:

struct Type {
	int delegate() prop() { return { return 0; }; }
}

Now, t.prop() will have a different meaning.

The problem here is that the trailing parenthesis pair () is allowed but not necessary. t.prop() could mean both t.prop and t.prop()().

/Oskar

Miles escribió:
> Jordan Miner wrote:
>> Sometimes using the property syntax causes a compiler error:
> 
> Properties are also broken for cases like:
> 
> 	button.width -= 5;
> 	cursor.position++;
> 
> This is the essence of properties (it should be completely transparent
> for the user if it is accessing a variable or calling a method), yet D
> doesn't support it properly. This has the potential to break a lot of
> code when you convert variables into properties.

I think you can add this to the thread "Python-like tabs instead of curley brackets?" where Walter says:

"Every programming language has some stupid mistake in it that sounded like a good idea at the time:
[other languages problems]
D: I'm sure you all have your own ideas for this!"

I mean, properties are great, but to be really useful they have to support the same semantics as regular variables. Maybe somethig as simple as translating button.width -= 5; as cursor.position = button.width - 5; is enough. Postfix incrementation is maybe the only problematic one, but could be done with something like:
{
	auto tmp = cursor.position;
	cursor.position = cursor.position + 1;
	return tmp;
}
(I think you'll get the idea ;)

This last scheme could be generally used to implement the other operators: 1) make a copy of the property 2) operate over the copy 3) update the property.

Or maybe the "stupid mistake" is deeper and it comes from the side of treating differently POD and objects...

-- 
Leandro Lucarella
Integratech S.A.
4571-5252

Some nitpicks :)

Leandro Lucarella wrote:
> I mean, properties are great, but to be really useful they have to support the same semantics as regular variables. Maybe somethig as simple as translating button.width -= 5; as cursor.position = button.width - 5; is enough. Postfix incrementation is maybe the only 

I think that cursor.position should be button.width...

> problematic one, but could be done with something like:
> {
>     auto tmp = cursor.position;
>     cursor.position = cursor.position + 1;

Surely you mean 'cursor.position = tmp + 1;'?

>     return tmp;
> }

Frits van Bommel escribió:
> Some nitpicks :)
> 
> Leandro Lucarella wrote:
>> I mean, properties are great, but to be really useful they have to support the same semantics as regular variables. Maybe somethig as simple as translating button.width -= 5; as cursor.position = button.width - 5; is enough. Postfix incrementation is maybe the only 
> 
> I think that cursor.position should be button.width...

Yup! =)

>> problematic one, but could be done with something like:
>> {
>>     auto tmp = cursor.position;
>>     cursor.position = cursor.position + 1;
> 
> Surely you mean 'cursor.position = tmp + 1;'?

Well, they have the same value at that point, so what's the difference?

>>     return tmp;
>> }


-- 
Leandro Lucarella
Integratech S.A.
4571-5252

Leandro Lucarella wrote:
> Frits van Bommel escribió:
>> Some nitpicks :)
>>
>> Leandro Lucarella wrote:
<snip>
>>> problematic one, but could be done with something like:
>>> {
>>>     auto tmp = cursor.position;
>>>     cursor.position = cursor.position + 1;
>>
>> Surely you mean 'cursor.position = tmp + 1;'?
> 
> Well, they have the same value at that point, so what's the difference?

Sorry, I thought cursor.position was a property?
If so, the way you wrote it the getter would be called twice as opposed to once with the rewrite.
If the getter returned something else the second time[1] then the returned value wouldn't even be one less than the new value[2].

Plus accessing a local variable is probably more efficient than calling a getter :).


[1]: This is probably pretty bad style, but it _is_ legal.
[2]: Unless of course the setter did something weird as well, but let's not get into that.

Bill Baxter wrote:
> janderson wrote:
>> Bill Baxter wrote:
>>> janderson wrote:
>>>>> It would be helpful if the following code would work:
>>>>>     enum TestEnum {
>>>>>         Value1, Value2
>>>>>     }
>>>>>     writefln("%s", TestEnum.Value2);
>>>
>>> I agree that I've wanted this kind of feature before too, but I don't
>>> want it at the expense of bloating every single library that contains
>>> enums with lots of string equivalents that will never get used in
>>> real code.  I.e. this kind of thing is really only useful for debug
>>> or prototype code.
>>> --bb
>>
>> I don't agree on this point (that it would only be used in debug).  As
>> I said, in scripting  (ie game ai ect...) and in plugin libraries (ie
>> maya) its common place to use a string lookup for enums.  The code
>> isn't *much* longer or more bug pron
>
> Mmmm -- bug pr0n.  *much* longer ... more bug pr0n....  :-)

sorry I ment: slightly more bug prone but not much longer...

//enum -> string

enum A
{
  Value1,
...
};

string A[] =
{
  "Value1",
...
};


//string to enum

A AToString[char[]];

void register()
{
  AToString["Value1"] = Value;
  //ect...
}


Really not that much code.  Also a lot of times in C++ you register lots of things together...

struct AInfo
{
   string name;
   string discription;
   int cost;
};

string A[] =
{
  { "Value1", "Some value I picked", 10 },
...
};


>
>> to write unless you go the other way and want it to be efficient (ie
>> string->enum is more complex then enum->string).  Still both cases are
>> pretty trivial to write in code.
>>
>> I guess the main thing going for it is that users would recognize the
>> pattern much more quickly (ie readability) although it does reduce the
>> chance of offset errors (had one of those just the other day).
>>
>> -Joel
>
> Useful for bridging with scripting code. That's a good point.  Python
> has no enums either, so they sometimes get turned into strings when
> going into Python land.
>
> Hey Kirk if you're listening, what does PyD do with enums?
>
> --bb

janderson wrote:
> Bill Baxter wrote:
>  > janderson wrote:
>  >> Bill Baxter wrote:
>  >>> janderson wrote:
>  >>>>> It would be helpful if the following code would work:
>  >>>>>     enum TestEnum {
>  >>>>>         Value1, Value2
>  >>>>>     }
>  >>>>>     writefln("%s", TestEnum.Value2);
>  >>>
>  >>> I agree that I've wanted this kind of feature before too, but I don't
>  >>> want it at the expense of bloating every single library that contains
>  >>> enums with lots of string equivalents that will never get used in
>  >>> real code.  I.e. this kind of thing is really only useful for debug
>  >>> or prototype code.
>  >>> --bb
>  >>
>  >> I don't agree on this point (that it would only be used in debug).  As
>  >> I said, in scripting  (ie game ai ect...) and in plugin libraries (ie
>  >> maya) its common place to use a string lookup for enums.  The code
>  >> isn't *much* longer or more bug pron
>  >
>  > Mmmm -- bug pr0n.  *much* longer ... more bug pr0n....  :-)
> 
> sorry I ment: slightly more bug prone but not much longer...
> 
> //enum -> string
> 
> enum A
> {
>   Value1,
> ...
> };
> 
> string A[] =
> {
>   "Value1",
> ...
> };
> 
> 
> //string to enum
> 
> A AToString[char[]];
> 
> void register()
> {
>   AToString["Value1"] = Value;
>   //ect...
> }
> 
> 
> Really not that much code.  Also a lot of times in C++ you register lots of things together...
> 
> struct AInfo
> {
>    string name;
>    string discription;
>    int cost;
> };
> 
> string A[] =
> {
>   { "Value1", "Some value I picked", 10 },
> ...
> };
> 

For clarity that should be more like:

 AInfo A[] =
 {
   { "Value1", "Some value I picked", 10 },
 ...
 };


> 
>  >
>  >> to write unless you go the other way and want it to be efficient (ie
>  >> string->enum is more complex then enum->string).  Still both cases are
>  >> pretty trivial to write in code.
>  >>
>  >> I guess the main thing going for it is that users would recognize the
>  >> pattern much more quickly (ie readability) although it does reduce the
>  >> chance of offset errors (had one of those just the other day).
>  >>
>  >> -Joel
>  >
>  > Useful for bridging with scripting code. That's a good point.  Python
>  > has no enums either, so they sometimes get turned into strings when
>  > going into Python land.
>  >
>  > Hey Kirk if you're listening, what does PyD do with enums?
>  >
>  > --bb

Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jordan Miner schrieb am 2006-12-02:
> 
>> --1--
>> The following does not work, but it really should:
>> 	void print(char[][] strs) { }
>> 	print(["Matt", "Andrew"]);
>> Gives:
>> 	Error: cannot implicitly convert expression ("Andrew") of type char[6] to char[4]
> 
> current by-pass:
>  	print([cast(char[])"Matt", "Andrew"]);
> 
> Thomas
> 

Or just:
  print(["Matt"[], "Andrew"]);


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D