On Wed, Jun 27, 2007 at 11:36:23PM -0700, michael.a wrote:
> mark-28 wrote:
> > I don't understand what is being requested. Have one structure with
> > four fields, and another with two, and allow them to be used
> > automatically interchangeably? How is this a good thing? How will
> > this prevent the implementor from making a stupid mistake?
> Its less a question of making a stupid mistake, as code being intelligible
> for whoever must work with it / pick it up quickly out of the blue. The more
> intelligible (less convoluted) it is, the easier it is to quickly grasp what
> is going on at the macroscopic as well as the microscopic levels. The way I
> personally program, typically a comment generally only adds obscusification
> to code which already more effeciently betrays its own function.
I agree with the sentiment, but not with the relevance. I don't see
how having a four field structure automatically appear as a completley
different two field structure, based only upon a match up between
field types and names seems more complicated and magical to me.
> Also syntacticly, I think its bad form for a function to simply access a
> data member directly / fudge its type. A function should imply that
> something functional is happening (or could be happening -- in the case of
> protected data / functionality)
This would disagree with much of the modern programming world. Black box
programming implies that you do not need to know whether a field is a real
field, or whether it is derived from other fields. Syntactically, it sounds
you are asking for operator overloading on fields, which maps to properties
in some other language. This is not more "simpler", as it only conceals
that a function may be performed underneath. It may look prettier, or use
fewer symbol characters.
Even so - I don't see why the following simplification of the example
provided would not suffice for your listed requirement:
class Rectangle {
Vector2d position;
Vector2d size;
};
... rectangle.position.x = ... ...
To have these automatically be treated as compatible types seems very
wrong:
class Rectangle { int x, y, w, h; };
class Vector2d { int dx, dy; };
Imagine the fields were re-arranged:
class Rectangle { int y, x, h, w; };
class Vector2d { int dx, dy; };
Now, what should it do?
> Granted, often intelligibility can demand too much semantic overhead from
> strict languages like c, but just as often perhaps, in just such a case, a
> simple accommodation is plainly obvious.
My best interpretation of this thread is that you are substituting
itnelligibility with DWIM, where DWIM for you is not the same as DWIM
for me, and I don't believe you could write out what your DWIM
expectation is in a way that would not break.
Cheers,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
