Re: Accessing types by context
On 29/06/16 05:11, Hiemlick Hiemlicker wrote:
Suppose one has void test(myEnum e)
enum myEnum
{
A,B,C
}
It would be very cool if we could do
test(A) instead of test(myEnum.A).
by context, the compiler can look first in the scope for something named
A then look in the enum itself and prepend myEnum internally.
Swift has this feature (the enum member needs to be prefix with a dot).
This has been brought up before and Walter doesn't like it. It will
complicate the language, especially function overloading:
enum Foo { A }
enum Bar { A }
void foo(Foo);
void foo(Bar);
foo(A); // ambiguity
--
/Jacob Carlborg
Re: Accessing types by context
On Wednesday, 29 June 2016 at 10:51:39 UTC, qznc wrote:
On Wednesday, 29 June 2016 at 03:11:52 UTC, Hiemlick Hiemlicker
wrote:
Suppose one has void test(myEnum e)
enum myEnum
{
A,B,C
}
It would be very cool if we could do
test(A) instead of test(myEnum.A).
by context, the compiler can look first in the scope for
something named A then look in the enum itself and prepend
myEnum internally.
Can you expand on "then look in the enum itself"? Which enum?
How to find the correct myEnum, if there is also myEnum2 and
myEnum3?
I think he means that function 'test' is declared with a
parameter of type 'myEnum',
so the only two scopes to look up are the current one and the
correct enum 'myEnum', because other enums won't match the
function parameter type.
If there are two overloads of 'test', with different enums that
share a member name, the compiler complains about ambiguity.
But maybe this is difficult to accomplish in the compiler, and
not worth the advantage.
The problem with implicit lookups is that you might
accidentally insert bugs when editing somewhere else. This is
why D forbids shadowing variables in general. For example:
With the behaviour I wrote above, there would be no way to insert
bugs; the worst thing would be the compiler rejecting the line as
wrong, even if you didn't touch it.
class Foo {
int x;
void bar(int a) {
baz(x);
return a+1;
}
}
Now imagine someone changed the variable "a" into "x". That
would change the behavior of "baz(x)" although you did not
change the line at all. I have the habit to always prepend this
as in "this.x" from Python. It avoids such errors.
Back to enums: If someone inserts another myEnum42 which also
has A, the code might suddenly pick the wrong A. The other way
round, if you delete myEnum, maybe it finds another A somewhere
else. The with-statement makes this explicit and thus more
reliable with respect to changes elsewhere.
It wouldn't be ambiguous (as I said above).
Nonetheless, I'm not a huge fan of this extension request.
Re: Accessing types by context
On Wednesday, 29 June 2016 at 03:11:52 UTC, Hiemlick Hiemlicker
wrote:
Suppose one has void test(myEnum e)
enum myEnum
{
A,B,C
}
It would be very cool if we could do
test(A) instead of test(myEnum.A).
by context, the compiler can look first in the scope for
something named A then look in the enum itself and prepend
myEnum internally.
Can you expand on "then look in the enum itself"? Which enum? How
to find the correct myEnum, if there is also myEnum2 and myEnum3?
The problem with implicit lookups is that you might accidentally
insert bugs when editing somewhere else. This is why D forbids
shadowing variables in general. For example:
class Foo {
int x;
void bar(int a) {
baz(x);
return a+1;
}
}
Now imagine someone changed the variable "a" into "x". That would
change the behavior of "baz(x)" although you did not change the
line at all. I have the habit to always prepend this as in
"this.x" from Python. It avoids such errors.
Back to enums: If someone inserts another myEnum42 which also has
A, the code might suddenly pick the wrong A. The other way round,
if you delete myEnum, maybe it finds another A somewhere else.
The with-statement makes this explicit and thus more reliable
with respect to changes elsewhere.
Re: Accessing types by context
On Wednesday, 29 June 2016 at 05:06:08 UTC, Hiemlick Hiemlicker
wrote:
On Wednesday, 29 June 2016 at 03:50:35 UTC, Carl Vogel wrote:
On Wednesday, 29 June 2016 at 03:11:52 UTC, Hiemlick
[...]
Doesn't the with statement solve your problem here?
with (myEnum) {
test(A);
test(B);
test(C);
}
Not really it's, only half the way there. Why not extend the
language the extra step?
I'm not sure I understand how it doesn't. Inside the with scope
you could refer to myEnum members by their (unqualified) names
alone. Isn't this the behaviour you're asking for?
As a pet peeve of mine, it's unfortunate that with: cannot be
used as attributes can, to last until the end of the current
scope without adding a new one.
void foo()
{
with(myEnum): // doesn't work
test(A);
test(B);
test(C);
}
Re: Accessing types by context
On Wednesday, 29 June 2016 at 04:34:26 UTC, Chang Long wrote: On Wednesday, 29 June 2016 at 03:11:52 UTC, Hiemlick Hiemlicker wrote: test(myEnum.A | myEnum.B & myEnum.C). I like this: myEnum.( A | B & C) == myEnum.A | myEnum.B & myEnum.C Does that even work? Regardless, You still have littered the code with the same context.
Re: Accessing types by context
On Wednesday, 29 June 2016 at 03:50:35 UTC, Carl Vogel wrote:
On Wednesday, 29 June 2016 at 03:11:52 UTC, Hiemlick Hiemlicker
wrote:
Suppose one has void test(myEnum e)
enum myEnum
{
A,B,C
}
[...]
Doesn't the with statement solve your problem here?
with (myEnum) {
test(A);
test(B);
test(C);
}
Not really it's, only half the way there. Why not extend the
language the extra step?
Re: Accessing types by context
On Wednesday, 29 June 2016 at 03:11:52 UTC, Hiemlick Hiemlicker wrote: test(myEnum.A | myEnum.B & myEnum.C). I like this: myEnum.( A | B & C) == myEnum.A | myEnum.B & myEnum.C
Re: Accessing types by context
On Wednesday, 29 June 2016 at 03:11:52 UTC, Hiemlick Hiemlicker
wrote:
Suppose one has void test(myEnum e)
enum myEnum
{
A,B,C
}
[...]
Doesn't the with statement solve your problem here?
with (myEnum) {
test(A);
test(B);
test(C);
}
Accessing types by context
Suppose one has void test(myEnum e)
enum myEnum
{
A,B,C
}
It would be very cool if we could do
test(A) instead of test(myEnum.A).
by context, the compiler can look first in the scope for
something named A then look in the enum itself and prepend myEnum
internally.
For flags, it would make it much easier to combine them:
test(A | B & C)
instead of
test(myEnum.A | myEnum.B & myEnum.C).
Similarly for comparisions of enums with objects:
if (object == A)
instead of
if (object == myEnum.A)
only if object is of type myEnum and A is not defined.
Seems logical? Is it possible in D to achieve something like this?
This could be extended to classes and structs but might create
too much confusions.
For enums, I don't see any reason why it wouldn't work well.
Just a thought. Prefixing the same id to everything gets tiring
after a while.
