Re: My 10c on namespaces
----- Original Message -----
From: "Alan Oxley" <fizzpop at icon.co.za>
To: "EUforum" <EUforum at topica.com>
Subject: My 10c on namespaces
Howzit Alan,
>
> Whatever the technical syntax Rob goes for, I hope that these factors are
> considered, in order:
> 1. Clarity.
> 2. Flexibility
> 3. Redundancy of previous code
>
> Clarity comes first, because its of vital importance for the program
creator
> (and anyone else)
> to understand what the intent of the code is. Hopefully with a minimum of
> comments or
> reading manuals.
I agree with all this stuff. And I'd even add "Simplicity" as well.
I have a big sign in my office that reads: "Is it Simple? Is it Clear?". I
need reminding of this principle often because its very easy to get complex
and obscure.
> A silly example: Personally I don't code in the format "a
> += 1" because:
> a) Its more obscure than "a = a + 1" and therefore harder to understand,
> particularly for newbies.
> b) It appears to be a "neat trick" from another language. Why? Who are we
> trying to impress?
> c) Using it makes old code break, for virtually no gain.
> d) Why are we wasting Rob's time, altering his parser for something so
> inconsequential?
Okay, here we differ. But ain't that just like us humans. Put 3 people into
a room and you get 4 mutually exclusive opinions!
When I first started to program in languages that used the "a = a + 1"
syntax, I found it very amusing because I came from a maths background, and
the formula "a = a + 1" doesn't make algebraic sense. I started with COBOL
and used the "add 1 to a" syntax - wordy it made sense to me. Later, when I
came across 'C' with its "a++" and "a += 1" syntax, I yelled "Hooray! Now
this is clever. This will make my code easier to understand." Weird eh!?
I went from writing such things as ...
(vCustomer->AuditCount) = (vCustomer->AuditCount) + 1;
to
(vCustomer->AuditCount)++;
which to my eye is simpler and clearer.
As for the "neat trick" idea. What's wrong with borrowing useful concepts
from other languages! Imagine if every language had to be totally different
from the next. You'd end up with APL or Forth 
The idea of avoiding neat tricks also sounds like a variation of the "not
invented here" syndrome.
How does using "a += 1" break old code? It might break old versions of
Euphoria though. But I'm sure don't mean that we should never upgrade
Euphoria to get improved functionality. If you don't want to use "a += 1"
then don't. No one is forcing you to.
Hmmmm, "inconsequential". And yet to me, this simple construct indicates a
maturity of thought in the product and an effort to make the users' life
easier. Nowadays I regard languages that don't support this construct as
old-fashioned and ornery. But this is all just opinion, eh?
> We are using Euphoria because it is clear, easy, stable, quick etc. Not
> because it is the same as something else.
Exactly! But this doesn't mean Euphoria is as good as it can get, yet!
> Flexibility - as in the solution/syntax should allow for as many factors
as
> possible. Eg, have a
> solution that elegantly (and clearly) handles subsequent references to a
> variable as the second
> reference. Don't build in restrictions that are not required. Do have
> meaningful error messages
> and options that can be used on demand.
Great stuff.
> Redundancy.. ie breaking of old code is less important then the
> abovementioned two factors
> IMHO, despite argument to the contrary . Why?
> a) Euphoria must move forward. Using an obscure solution that does not
break
> old code may set us
> up for a headache that will never go away. The listserv will abound with
> the same tired explanations
> of why it works that way. Answering the "Why couldn't Euphoria have done
> this easier (CLEARER)"
> and "Why does this (seemingly obvious) code not work" will be right up
> there with the "How do
> I get off this list" used to be, or "deleteItem does not work"... Ring a
> bell, Derek ?
Have not got a clue
> b) How much old code do we REALLY use, both in bytes and in persons doing
> it? With the
> exception of Win32lib, I would suggest not much. IMHO those skilled
> enough to include others'
> code, will be skilled enough to make the required changes. I submit that
> most old code written
> by others is purely reference material.
> c) Nothing is stopping us from binding old code and using the executable,
> until such time as we
> get around to correcting the breakages brought about by the namespace
> solution. Even simply
> persisting with the old release of Euphoria would work.
I'm a little confused here. Earlier you seemed to be concerned that "a += 1"
would break old code but now you're saying that is the price one pays for
progress. Did I miss something?
IMHO, I believe it will be possible to come up with a namespace solution
that will not force existing code to be changed.
> Rob, how about putting the suggestions up on rapideuphoria.com , and
> allowing licenced users
> to vote? Each methodology to have the pros and cons mentioned.
> You don't have to go for the most popular of course ;)
>
I've suggested this to Robert privately some time back. He would rather not.
He has another system for keeping tabs on wishlist items. I'm just glad he
is allowing us the opportunity to comment on this important addition to the
language before he commits it to code.
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, work slower."
|
Not Categorized, Please Help
|
|
