Fri, 27 Nov 2009 14:10:34 +0100, Danny Wilson wrote:
> Op Fri, 27 Nov 2009 11:58:59 +0100 schreef Don :
>
>>> void foo()
>>> @naked body
>>> {
>>
>> LOL! Spam filters would love that!!
>
> I can already imagine the jokes spreading over the internets:
>
> @safe public double penetration(of a) @n
Lutger wrote:
I tend to think attributes in .NET are a regular means of abstraction, much
like classes or generics. In part, they make up for lack of other
metaprogramming features in some .NET languages.
I agree; I think they are best for associating arbitrary information
with arbitrary type
Don wrote:
> Ary Borenszweig wrote:
>> Don wrote:
>>> #ponce wrote:
> Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
>>>
>>> As I understand it, one of the characteristics of attributes is that
>>> you shoul
Don wrote:
> It seems that pure and nothrow are attributes, just like @safe.
> (By contrast, you can overload functions based on const and immutable).
> Should the names be changed?
This runs into another issue I was thinking about.
So I'm working on this property rewrite thing that does the foll
Ary Borenszweig wrote:
Don wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that
you should be able to remove them from the entire
Don wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that you
should be able to remove them from the entire program, without affect
Denis Koroskin, el 27 de noviembre a las 12:17 me escribiste:
> On Fri, 27 Nov 2009 12:09:05 +0300, Don wrote:
>
> >#ponce wrote:
> >>>Definitely. And what about @deprecated and @override?
> >> As override is now required, i don't think it should be an attribute.
> >
> >As I understand it, one of
Op Fri, 27 Nov 2009 11:58:59 +0100 schreef Don :
void foo()
@naked body
{
LOL! Spam filters would love that!!
I can already imagine the jokes spreading over the internets:
@safe public double penetration(of a) @naked body { ... }
Don wrote:
Lars T. Kyllingstad wrote:
Don wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that
you should be able to remove them
Lars T. Kyllingstad wrote:
Don wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that
you should be able to remove them from the en
Denis Koroskin wrote:
On Fri, 27 Nov 2009 13:58:59 +0300, Don wrote:
Denis Koroskin wrote:
On Fri, 27 Nov 2009 12:50:19 +0300, bearophile
wrote:
Walter Bright:
Naked is not an externally visible attribute of a function,
signature or
type, it only concerns the internals. Therefore, it
Denis Koroskin:
> I think "do not affect the generated code" is a bit restricting.
> [...] There are endless possibilities.
Lombok gives annotations to reduce boring lines of Java code:
http://projectlombok.org/features/index.html
Some of those annotations:
@Getter / @Setter: Never write public
On Fri, 27 Nov 2009 13:56:10 +0300, Lars T. Kyllingstad
wrote:
Don wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that
you s
On Fri, 27 Nov 2009 13:58:59 +0300, Don wrote:
Denis Koroskin wrote:
On Fri, 27 Nov 2009 12:50:19 +0300, bearophile
wrote:
Walter Bright:
Naked is not an externally visible attribute of a function, signature
or
type, it only concerns the internals. Therefore, it shouldn't be an
attri
Denis Koroskin wrote:
On Fri, 27 Nov 2009 12:50:19 +0300, bearophile
wrote:
Walter Bright:
Naked is not an externally visible attribute of a function, signature or
type, it only concerns the internals. Therefore, it shouldn't be an
attribute.
On the other hand I agree with them that curr
Don wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that you
should be able to remove them from the entire program, without affect
On Fri, 27 Nov 2009 12:50:19 +0300, bearophile
wrote:
Walter Bright:
Naked is not an externally visible attribute of a function, signature or
type, it only concerns the internals. Therefore, it shouldn't be an
attribute.
On the other hand I agree with them that currently "naked" is not i
Walter Bright:
> Naked is not an externally visible attribute of a function, signature or
> type, it only concerns the internals. Therefore, it shouldn't be an
> attribute.
On the other hand I agree with them that currently "naked" is not in the best
place. So let's try another alternative:
On Fri, 27 Nov 2009 12:30:30 +0300, Lars T. Kyllingstad
wrote:
Denis Koroskin wrote:
On Fri, 27 Nov 2009 12:09:05 +0300, Don wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understan
Denis Koroskin wrote:
On Fri, 27 Nov 2009 12:09:05 +0300, Don wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that
you should b
On Fri, 27 Nov 2009 12:09:05 +0300, Don wrote:
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that you
should be able to remove them
#ponce wrote:
Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
As I understand it, one of the characteristics of attributes is that you
should be able to remove them from the entire program, without affecting
the beh
>
> Definitely. And what about @deprecated and @override?
As override is now required, i don't think it should be an attribute.
Don wrote:
It seems that pure and nothrow are attributes, just like @safe.
(By contrast, you can overload functions based on const and immutable).
Should the names be changed?
Definitely. And what about @deprecated and @override?
-Lars
== Quote from Don (nos...@nospam.com)'s article
> It seems that pure and nothrow are attributes, just like @safe.
> (By contrast, you can overload functions based on const and immutable).
> Should the names be changed?
Vote++. Now that we have attributes, I think this is a no brainer from a
consi
Denis Koroskin wrote:
On Fri, 27 Nov 2009 03:18:05 +0300, Don wrote:
It seems that pure and nothrow are attributes, just like @safe.
(By contrast, you can overload functions based on const and immutable).
Should the names be changed?
I agree. I also believe there should be @naked (it's somew
On Fri, 27 Nov 2009 03:18:05 +0300, Don wrote:
It seems that pure and nothrow are attributes, just like @safe.
(By contrast, you can overload functions based on const and immutable).
Should the names be changed?
I agree. I also believe there should be @naked (it's somewhat unintuitive
that
It seems that pure and nothrow are attributes, just like @safe.
(By contrast, you can overload functions based on const and immutable).
Should the names be changed?
28 matches
Mail list logo
