Hello,
I think the compiler should complain when sub-classes hold fields with the same
name as super-classes. After all, names (in addition to types) are used to
identify. Intentionally reusing the same name would not only be bad design, but
open the door to hidden bugs.
Remain unintentional n
spir wrote:
Hello,
I think the compiler should complain when sub-classes hold fields with the same
name as super-classes. After all, names (in addition to types) are used to
identify. Intentionally reusing the same name would not only be bad design, but
open the door to hidden bugs.
Remain u
spir:
> I think the compiler should complain when sub-classes hold fields with the
> same name as super-classes.
I have a bug report on it:
http://d.puremagic.com/issues/show_bug.cgi?id=5187
C# faces this problem with the "new" keyword that's denotes a field that the
programmer wants to hide:
On Sun, 14 Nov 2010 22:09:59 +0300
Stanislav Blinov wrote:
> spir wrote:
> > Hello,
> >
> >
> > I think the compiler should complain when sub-classes hold fields with the
> > same name as super-classes. After all, names (in addition to types) are
> > used to identify. Intentionally reusing th
Stanislav Blinov schrieb:
spir wrote:
Hello,
I think the compiler should complain when sub-classes hold fields with
the same name as super-classes. After all, names (in addition to
types) are used to identify. Intentionally reusing the same name would
not only be bad design, but open the do
On Sun, 14 Nov 2010 14:22:56 -0500
bearophile wrote:
> spir:
>
> > I think the compiler should complain when sub-classes hold fields with the
> > same name as super-classes.
>
> I have a bug report on it:
> http://d.puremagic.com/issues/show_bug.cgi?id=5187
You have bug reports for everything
spir:
> What are use cases for this? (And wouldn't it be better practice to change
> name even in supposed sensible cases?)
I don't know. C# shows a warning if an attribute is masked by another one. Then
I think they have added that "new" syntax as a clean way to silence that
warning. (I am no
On Sunday 14 November 2010 11:29:55 spir wrote:
> On Sun, 14 Nov 2010 22:09:59 +0300
> Stanislav Blinov wrote:
> > This issue has been brought up several times before. I myself see no
> > harm in this shadowing, though making a compiler issue a warning
> > when shadowing *public* fields occurs wou
Stanislav Blinov wrote:
> The other option that comes to mind is
... support protocols for variables in non-release mode.
-manfred
On Sun, 14 Nov 2010 16:25:56 -0800
Jonathan M Davis wrote:
> On Sunday 14 November 2010 11:29:55 spir wrote:
> > I don't understand in which case you need to reuse the same name in a
> > subclass for a _different_ field -- whether the field is public or private
> > does not seem really relevant t
Daniel Gibson wrote:
Stanislav Blinov schrieb:
spir wrote:
Hello,
I think the compiler should complain when sub-classes hold fields
with the same name as super-classes. After all, names (in addition to
types) are used to identify. Intentionally reusing the same name
would not only be bad d
On Monday 15 November 2010 02:29:55 Stanislav Blinov wrote:
> Daniel Gibson wrote:
> > Disallowing public fields is too restrictive IMHO.
>
> Maybe. I just always view public fields as encapsulation breakers. And
> silent invariant breakers. And maintenance cripplers :)
Personally, it's the kind
Jonathan M Davis wrote:
> Having public fields shadow each other is problematic.
Detecting a problem requires having a model.
What does your model look like?
-manfred
On Monday, November 15, 2010 06:00:33 Manfred_Nowak wrote:
> Jonathan M Davis wrote:
> > Having public fields shadow each other is problematic.
>
> Detecting a problem requires having a model.
> What does your model look like?
You're going to have to be more specific in your question than that. I
On Mon, 15 Nov 2010 09:45:26 -0800
Jonathan M Davis wrote:
> On Monday, November 15, 2010 06:00:33 Manfred_Nowak wrote:
> > Jonathan M Davis wrote:
> > > Having public fields shadow each other is problematic.
> >
> > Detecting a problem requires having a model.
> > What does your model look like
On Monday 15 November 2010 11:44:11 spir wrote:
> On Mon, 15 Nov 2010 09:45:26 -0800
>
> Jonathan M Davis wrote:
> > On Monday, November 15, 2010 06:00:33 Manfred_Nowak wrote:
> > > Jonathan M Davis wrote:
> > > > Having public fields shadow each other is problematic.
> > >
> > > Detecting a pro
Jonathan M Davis wrote:
> It becomes easy to end up in a situation
> where you're not using the one that you think that you're using
Which means that the model one is thinking in, is inconsistent with the
model used in fact.
The OP used a model in which a name becomes invisible by redefinition
On Mon, 15 Nov 2010 12:32:07 -0800
Jonathan M Davis wrote:
> On Monday 15 November 2010 11:44:11 spir wrote:
> > On Mon, 15 Nov 2010 09:45:26 -0800
> >
> > Jonathan M Davis wrote:
> > > On Monday, November 15, 2010 06:00:33 Manfred_Nowak wrote:
> > > > Jonathan M Davis wrote:
> > > > > Having p
spir:
> (and bug-prone, because sometimes the absence of a fields seems not caught,
> for any reason), so I add fields to the top type.
What do you mean? Do you have an example?
(Adding fields to the top type doesn't look like a good idea, generally).
Bye,
bearophile
On Tue, 16 Nov 2010 05:37:52 -0500
bearophile wrote:
> spir:
>
> > (and bug-prone, because sometimes the absence of a fields seems not caught,
> > for any reason), so I add fields to the top type.
>
> What do you mean? Do you have an example?
> (Adding fields to the top type doesn't look like
On Tue, 16 Nov 2010 05:37:52 -0500
bearophile wrote:
> spir:
>
> > (and bug-prone, because sometimes the absence of a fields seems not caught,
> > for any reason), so I add fields to the top type.
>
> What do you mean? Do you have an example?
> (Adding fields to the top type doesn't look like
On 16.11.2010 14:40, spir wrote:
On Tue, 16 Nov 2010 05:37:52 -0500
bearophile wrote:
spir:
(and bug-prone, because sometimes the absence of a fields seems not caught, for
any reason), so I add fields to the top type.
What do you mean? Do you have an example?
(Adding fields to the top type
On Tuesday, November 16, 2010 03:40:24 spir wrote:
> On Tue, 16 Nov 2010 05:37:52 -0500
>
> bearophile wrote:
> > spir:
> > > (and bug-prone, because sometimes the absence of a fields seems not
> > > caught, for any reason), so I add fields to the top type.
> >
> > What do you mean? Do you have
23 matches
Mail list logo
