[Harbour] CaseStudy: an alternative to Hungarian notation for aHigh-Level language such as [x]Harbour

[frank van nuffel]

Hello Pritpal,

1) personally i prefered an OO approach to everything in Ca-Clipper, making
abstraction of possible procedural backtranslations under the hood (before
compilation); on source level (o)ceans' delivers a uniform syntax, using
polymorphism to the maximum so as to never have to lookup strange compact
names for functions (such as in Ca-Clipper Tools library) - by saying
everything, i mean that also functions which can't be associated with native
types are taking profit of polymorphism in (o)ceans' by means of a
construction which closely relates to namespaces; once this level is well
thought (*) source code will never reflect legacy names anymore; the main
advantage might be that the whole interface can become more human memory
friendly, but i admit people who have worked all their life with the legacy
namings will feel reluctant to switch to a new scheme, especially, as
mentioned, when the new names are but just backtranslated procedurally (to
the old names - this is the case when an upfront uppercase is used in the
type mnemonic in the scope operation as explained, and i'd like this to be
supported for a possible performance gain when executed procedurally)

(*) designing this alternative OO implementation is really a grand
opportunity to do it completely anew; doing it right might be dependant of a
democratic approach or one, while still open to suggestions (especially for
the actual namepart), that is governed by a strict set of prescriptions as
to how building it up; (o)ceans' actually doesn't imply more than this set
of guidelines, but to anticipate to your last question, my feeling is that
for it to be finalized _per_ library, given providing occasion to welcoming
suggestions - again, especially for the actual naming part - from the
community, it could last a while before settling into a final api.  In the
meantime, as for me, i've made lots of decisions already for a couple of
libraries, but this is kept private, thus free to change whenever i feel
like.

Here's the good news for those that want take off already with an OO
approach for native types; (o)ceans' provides a parrallell api _per_ native
type, where the message names are identical to the original function names;
while this is definitely not taking advantage of polymorphism, the fact that
the original function names are most certainly unique among each other (for
them to appear in the symbol table without clashing), guarantees that a tool
(though still to be implemented) can safely recognize these native type
messages to translate them to the final api when it will be ready.  Or,
concurrently, the legacy message names will be mapped onto the new api names
by means of simple MESSAGE ... IS ... code.

With devel access, in a really short timeframe, this could already to done
by means of the available OO support for native types

As to OO for native types by itself, except for the reasons mentioned
(polymorphism/uniformity in coding style), it may or may not be an
additional processing hurdle at runtime, depending on whether it can be
fully optimized, also at the C level; when an original function is
implemented at prg level, the code can move right into the native type
class, switching to what (o)ceans' calls a 'message/function' - this is a
function bearing its original legacy names, so that procedural calling can
still occur, but at the same time it acts as a message; not only because it
is listed in the type's class definition (in Class(y) that would be by means
of a MESSAGE newAPImessageName METHOD oldAPIfunctionName; i'm not sure how
it's done in Harbour) but also at the entrypoint of the 'message/function' -
if QSelf() is empty then it has been called procedurally, else it has been
called in OO style; this has consequences to the argument list to be
processed, but once that is fixed at entrypoint, the original code to the
function may start executing; the only penalty to this implementation is
this entrypoint fixup, other than, when called in an OO manner, a message
lookup in the class object must be perfomed, but i guess this comes closely
to the same as a function lookup in the symbol table.  When an original
function is implemented in C, the same entrypoint fixup can be provided
(i've done tests and it works well at the C level also) as to enable C
functions to become 'message/function's also.

2) yes, i've been assured it can coexist

3) in short: have someone (i can do it, but will need devel access) provide
exactly to legacy function corresponding message names for all the native
types, and you're set - when the final api (on a _per_ library basis) is
ready, a tool can help your code to be transformed reflecting the new names, 
or even execute without this translation thru the MESSAGE oldName IS newName

stay tuned as for an example in this forum, or check your private email
(whichever i'll opt for first)

best regards,

frank van nuffel
lohen at versateladsl.be

From: "Pritpal Bedi" Sent: Friday, December 14, 2007 9:52 PM
Subject: Re: [Harbour] CaseStudy: an alternative to Hungarian notation for
aHigh-Level language such as [x]Harbour


> A good thought and eleborate explanation.
>
> However, this comes to me as is:
>
> 1) What benefits ( except from self documentation ) we can derive out of
> it?
> 2) Will this coexist with existing OO modal?
> 3) How long it will take to implement this construct?
>
> Please post a realtime function example, will be more appropriate it
> Tbrowse() is taken as a modal, to understand the underlying concepts
> better.
>
> Regards
> Pritpal Bedi, INDIA-USA
>
> P.S. BTW I hear you after long time, probably since 2002.
>
> -- 
> View this message in context:
> http://www.nabble.com/CaseStudy%3A-an-alternative-to-Hungarian-notation-for-a-High-Level-language-such-as--x-Harbour-tp14339266p14339791.html
> Sent from the Harbour - Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Harbour mailing list
> Harbour at harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.17.2/1184 - Release Date:
> 14/12/2007 11:29
>
>