Code aesthetics as you put it is a big deal for me as well. One of
the biggest problems I'm having as I attempt to lean NET via VS w/Chrome,
and even though Chrome is native Pascal, is that other's code I'm reading is
very tough due to the differences in use and syntax structure. In my Delphi
code I even go so far as to never use 'not' or shortcut
begin...end...else...begin...end; pairs! I figure it doesn't matter to the
compiler, which is going to optimize it on the final run anyway so I might
as well be as literal as I can be! I'll never get used to see inline vars
like they're using in Chrome though! <g>
from Robert Meek dba Tangentals Design CCopyright 2006
Proud to be a moderator of "The Delphi Lists" at elists.org
"When I examine myself and my methods of thought, I come to the conclusion
that the gift of Fantasy has meant more to me then my talent for absorbing
positive knowledge!"
Albert Einstein
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Sean ROBINS
Sent: Friday, August 04, 2006 12:08 AM
To: Borland's Delphi Discussion List
Subject: RE: Declaration of types/constants within the class interface
Thanks to Mick, Stephen and John for your replies. I respond to each of
your responses below
> The main 'benefits' I've found are
> 1) much tighter control of scope.
Yup, as a programmer I can lock everything away more.
> 2) declare as you need a variable
Still can't be done in Delphi, and I'm glad this is the case as it makes
me think before I use a variable (and hopefully discourages me from
reusing variables inappropriately).
> The obvious 'disadvantages' are
> 1) lack of forward planning
Meaning I should be careful before I choose to lock everything away!
;-)
> 2) more difficult to read and debug code (though dynamic
> debugging the application is sometimes easier)
Code aesthetics! I am a BIG fan of making everything simple to read
through. I can't decide if I like this syntax or not. On the one hand,
everything associated with the class is grouped together in the one
place, while on the other, the functional interface of the class seems
to be polluted, at least for Delphi anyway. Seems embedded types just
look a whole lot neater in Java and C#.
> You could always do this - it is encapsulation.
<contradictory mode>
Not exactly.
</contradictory mode>
The concept of encapsulation has always been supported in the basic OO
sense, with Delphi providing appropriate visibility specifiers for that
very purpose. The encapsulation of types or constants as subtypes has
only been supported in versions of Delphi later than version 7. For
those of us in the "dark ages" :-) and still supporting Win32
applications, this means that Delphi2005 introduced something 'new'
which C++ and Java developers had apparently been doing for years.
If encapsulation (and by definition visibility) of types is the primary
concern, then I could always declare types and constants in the
implementation section of the code. Messy if such classes need to be
member properties of the more visible class declared in the interface
section, but do-able all the same.
> Type
> TBookings = class( TMyBaseObject)
> const
> TBookingStatus = [bsUnbooked, bsBooked, bsDispatched,
> bsPickedUp, bsDelivered, bsError];
>
> TBookingString : array [bsUnbooked .. bsError] : string[10] =
> ('Unbooked', and so on
The real question is, why push the concept of encapsulation to the limit
and nest entire classes, constants and other types within the body of a
class? In the example quoted above, the enumerated type
(TBookingStatus) which might only be contextually useful related to the
class it was declared in might also be used by other objects within the
system. Two immediate examples that come to mind are as the basis for a
drop down list, or to validate an entry in a data table. Granted the
nested types could be made public for accessibility, so how is this any
different from declaring the type external to the class?
> It provides additional layers of "namespace" scoping for such items.
Ok, that answers my previous question. And actually, I think it's kind
of cool that I can declare a variable like this:
var
obj: TClassType.TSubClassType;
And especially cool that the IDE will happily handle the code completion
for me. However, if simple namespacing is an issue, how is this any
different to the following?:
var
obj: ClassTypeUnit.TSubClassType; // where TSubClassType was
declared externally instead.
> I suspect this syntax represents the Delphi support for
> certain .NET language features that was implemented for
> Delphi.NET and back-formed onto the language as a whole.
This makes a LOT of sense. Especially given the need to move DotNET
code around a number of different languages. It seems to have little
bearing on Win32 development though, so why bother adding the feature to
Delphi Win32? I'm guessing it was done to make porting applications to
DotNET much simpler... but that only really makes sense if the developer
wanted to use such syntax in the first place, as the code would port
just as easily without all of the type nesting.
> Are such declarations treated as "static" class properties?
> I.e. can they be accessed via the class name alone, or is an
> instance required?
I wrote a little test app to explore the syntax. Yes, the constants and
types that are nested are treated effectively as static properties of
the encapsulating class. This aspect of the syntax is kind of neat, as
I can make a whole bunch of class properties without the 'messy' class
specifier based syntax required when declaring class-level functions.
Maybe it's just me, and maybe I've grown a little set in my ways, but I
still can't really see much difference between new syntax and old. It
seems that all of the issues that this embedded syntax seems to deal
with already have an alternative way to be done that has been used by
Delphi programmers since the early version 2 days. Don't get me wrong,
I'm all for using the new syntax if it makes sense. My primary concerns
are with the disadvantages that the syntax my introduce. What I still
don't know is if there are any memory-space issues that need to be
understood. What happens if I subclass and need to override the
behaviour in the parent class's subtypes, and can this even be done?
Putting my software architect hat on, what design issues might arise if
I do this sort of thing in Delphi, and what considerations do I need to
make in order to avoid the potential pitfalls. And most importantly,
are there any pitfalls that need to be considered in the medium to long
term, or am I just worrying over nothing?
Sorry for the long post. It's just one of those issues that the more I
research, the less information I can find 'out there', and I prefer do
things programming/design-wise for a rational reason that takes into
account performance, development time, supportability, and other key
measurables, rather than doing something because it looks cool, or
because everyone else is doing it!
Cheers,
S.
Sean Robins
Senior Programmer
Dynamic Hearing Pty Ltd
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
