grabbing value of a variabe by its name?

Ragnar Hojland Espinosa ragnar at linalco.com
Mon Jul 29 17:29:23 UTC 2002


On Mon, Jul 29, 2002 at 03:21:24PM +1200, Richard A. O'Keefe wrote:
> Ragnar Hojland Espinosa <ragnar at linalco.com> is still trying to
> defend a maintenance-disaster-type pun.

*digests the email slooowly*

I'll defend it no longer as your "dark side of perl" reference woke me up.
It takes a bit to think in other ways than you do.  I still don't see it as
a maintenance disaster, but you all pointed to me there are other
interesting posibilities.  Anyway..

> This is doing things an OBJECT-ORIENTED way.  You want to insert something
> into a table.  What do you want to insert?  Variables?  No: you want to
> insert an OBJECT.  So let there *BE* an object.

Right.  However I'm using the postgres bindings which as far as I can see they
aren't as "objectified" as they could be (or I could be wrong), and I admit
I feel quite some reluctance to start messing with them and spreading
changes all over the place and ripping its guts apart.

> For example, suppose the column 'zip' in your data base is renamed from
> the US-centric 'zip' to a more globally intelligible 'postcode'.  ALL of
> your versions break, but the Table1 class can just add two methods

You don't go around renaming columns just because one is more intelligible to
you than what you "inherited", unless you are very bored.

>  * It simply isn't *POSSIBLE* to use the same names in your Smalltalk code
>    as in your data base.

It is, as long as you design your database and you dont have to access third
party ones, and thats the only reason I'm comfortable with pulling tricks
and "rules" out of my hat.  The rest of my reply revolves around this, so if
you agree you'll probabily agree with the rest.. and if you don't you'll
never agree with anything.

> ->     Home_Team            character(14),

All the columns have no underscores in them, on purpose, just to avoid this
inconvenience.

>  * The trick does not particularly encourage consistency.  SQL names are
>    not case sensitive.  So homeTeam, homeTEAM would both represent the
>    same SQL name.  How exactly does the trick encourage people to consistently
>    pick one of them, in a way that gentle exhortation would not?

Doesnt matter as the column names get lowercased when the postgres bindings
return them.  Or maybe its seaside.. they get lowercased somewhere.

>  * Sometimes in SQL you have to use qualified names.  The example data base
>    that my example comes from includes also
>     create table Teams (Team ...)
>     create table League (Team ...)
>    You have not yet explained how your pun can accomodate SQL names like
>    Teams.Team or League.Team.

select team.team as teamteam

>  * Some names which are perfectly usable as SQL names are reserved words
>    in Smalltalk, such as "self", "super", "nil".

That hardly counts as a valid objection.

>  * You have not yet explained how your pun can accomodate SQL delimited
>    identifiers.  For people who never looked at SQL 92, "foo!" (with the
>    double quotes) is a perfectly good SQL 92 'delimited identifier'.
>    Delimited identifiers may be used pretty much anywhere that simple
>    identifiers may be.

Who wants the shotgun?

>  * According to the SQL 1992 standard, an identifier may contain non-Latin
>    letters if such exist according to the <module character set specification>
>    or the <character set specification>; how are those to be handled by this
>    pun?

And the shells?

I've already been bitten by this trying to port an application some time
ago and its not getting anywhere near where I have a word to say about it.

> In this case, the two rows happen to need the same value for their
> 'team' columns.  But what if they needed DIFFERENT values for their
> team columns?
> 
>     winners := 'Hawkeyes'.
>     losers := 'Windies'.
>     w := Wins new.
>     w team: winners; against: losers.
>     w insert.
>     l := Losses new.
>     l team: losers; against: winners.
>     l insert.
> 
> I cannot for the life of me regard any approach which would force
> the entry into Wins and the entry into Losses to use the *same* local
> variables for opposite purposes as 'safe'.

Ah, you saved the real one for the end :)  It's a poor example tho (SQL
wise), but nobody is forcing you:  

If you want (or need) to write the insert statement, do.  Of course the
statement was more "exposed" and therefore looked more natural (or less
ugly) in my example than it would if it was next to your example.

Orrr..  w := Wins new.  w from: 'oldname' to: 'newname' or similar.

-- 
____/|  Ragnar Højland      Freedom - Linux - OpenGL |    Brainbench MVP
\ o.O|  PGP94C4B2F0D27DE025BE2302C104B78C56 B72F0822 | for Unix Programming
 =(_)=  "Thou shalt not follow the NULL pointer for  |  www.brainbench.com
   U     chaos and madness await thee at its end."             CCNA



More information about the Squeak-dev mailing list