Dolphin SmallTalk Value Edition AND MS Access

I am looking for some solution that will allow me to use Dolphin
SmallTalk Value Edition to write to any MS Access (97 through 2003)
database without purchasing the 179$ Standard Edition.  I am a college
student who is taking an Object-Oriented Development course and as a
pre-req for my Software Engineering degree, we must learn one language
on our own.  Because I have a vast background in VB, C++, Java, PERL,
and PHP, I was not able to choose one of those and chose SmallTalk
"mistakenly".  I was not aware that there were hardly no versions that
of SmallTalk that supported database connectivity.  I know Dolphin
SmallTalk has the STB file capability, but I need to access an RDBMS
such as Access.  I have written to Dolphin about a possible Academic
discount but he states they do not offer one for the Standard Edition,
however he did mention to me that you can develop your own ActiveX
components to create a database connection to Access.  Has anyone ran
across an ActiveX component such as this and if so, where did you find
it?  Has anyone working with the Value edition found a solution to
access MS Access databases?

Thanks for your time and help,

David B.

On 22 Sep 2005 07:20:58 -0700, David B <[hidden email]> wrote:

> I am looking for some solution that will allow me to use Dolphin
> SmallTalk Value Edition to write to any MS Access (97 through 2003)
> database without purchasing the 179$ Standard Edition.

I don't know about the limitations of the Value Edition,
but for educational purposes, you can also get

- Visual Works from Cincom
- Visual Age from IBM^H^H^HInstantiations
- ST/X from exept.de
- gnu smalltalk

most of these run on Windows, too, and at least the big players
should support ODBC connections out of the box.

s.

I have looked at those but Dolphin seems to be the most actively
updated distro.  IBM is cancelling support and updates for Visual Age
in April 2006, Visual Works does not support database connectivity out
of the box other than Excel from what I've seen.  Generally I'd like to
stay with Dolphin if I can.

You can interface with odbc32.dll which is what Dolphin's the database
package is doing.

--
Hwee Boon

David B wrote:

> I have looked at those but Dolphin seems to be the most actively
> updated distro.  IBM is cancelling support and updates for Visual Age
> in April 2006, Visual Works does not support database connectivity out
> of the box other than Excel from what I've seen.  Generally I'd like
> to stay with Dolphin if I can.

Well, this is what to do to get ODBC support (via Microsoft's Active
Data Objects) into Dolphin Value Edition:

1) Go to Tools/Additional Tools/ActiveX Component Wizard and start the
ActiveX Component Wizard.

2) Click Browse and scroll down the list to find the "Microsoft ActiveX
Data Objects 2.x" library and select that, then press Next.

3) The next page tells you that the various classes for this library
will be generated with a class prefix of ADODB and they will be placed
in a package called ADODB. These defaults are most likely what you want
so click the Next button again.

4) You will now be given a list of the interfaces in the ADO library so
select all of these and click Generate.  The wizard will then go away
and generate the appropriate interface classes.

It should now be fairly straightforward to use the Microsoft ADO
documentation to access your ODBC database.  See here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/
htm/mdmscsection1_ado.asp

Just as an example, let's say that you have set up the Microsoft
NorthWind example database and created an ODBC DSN of NWind for it.
Then, in a workspace you can do the following.  Put the cursor on each
line and use DisplayIt to evaluate and display the results one at a
time:

connection := ADODB_Connection new connectionString: 'DSN=NWind'.
connection open.
results := connection query: 'select LastName from employees'.
results MoveFirst.
row := results value.
(row at: 'LastName') value

Obviously, you can then use MoveNext to get subsequent rows from the
database. The version of the ADODB interface that is included with
Dolphin Standard Edition also has a number of helper methods that have
been added to the generated classes which make it easier to treat the
ADO objects more as Smalltalk expects them. However, I'll leave these
sort of niceties as an exercise for the student :-)

I know this is not going to help you with your current project but you
may be interested to know that the next release of DVE (which will be
entitled the Dolphin Community Edition) will include both database and
socket support as standard.

Best regards,

--
Andy Bower
Dolphin Support
www.object-arts.com

Andy,

Thank you so much for your help.  I will be looking forward to the
Community Edition release of Dolphin.

David B.

By the way - stick with learning Smalltalk (especially given your background
of other languages) - its a bit of a mind jolt at first but - you will
really learn proper object oriented programming.

People I encounter who have Smalltalk (and now possibly ruby and python)
experience seem to just "get" how to design good applications - people who
have only done VB and then moved to C# (in general) seem to really struggle.

On the horizon the new release Andy mentions has a nice IDE - so that really
makes it even more of a pleasure.

C# 3.0 is starting to look like its getting Smalltalk like features (loose
methods, duck typing, better closures) - but thats years away and even then
still looks a bit yucky.

Tim

p.s. Thinking back to my student days and learning Smalltalk after Pascal, I
found that I got the lightbulb when I discovered how #ifTrue: and #ifFalse:
worked.


"David B" <[hidden email]> wrote in message
news:[hidden email]...
> Andy,
>
> Thank you so much for your help.  I will be looking forward to the
> Community Edition release of Dolphin.
>
> David B.
>

TimM, David,

> p.s. Thinking back to my student days and learning Smalltalk after
> Pascal, I found that I got the lightbulb when I discovered how
> #ifTrue: and #ifFalse:  worked.

I think the light-bulb went on for me when I realised why there was no
switch/case statement in Smalltalk. This was many years after starting
to program in C++ and thinking I had become reasonably competent in it.
When I finally realized that the omission of switch/case was a
deliberate act rather than just an oversight that's when I first really
"grokked" OOP.

"The introduction of so-called object-oriented features (C++) into a
non-object oriented language (C) was a fundamentally bad idea and set
the whole software industry back 10 (now 25) years." Discuss.

Best regards,

--
Andy Bower
Dolphin Support
www.object-arts.com

I am starting to slowly come around with understanding SmallTalk.  An
article I read up on SmallTalk.org teaches some of the basic constructs
in relation to how Java presents them.  This got me started into
understanding SmallTalk better.  The biggest help to learning and
understanding SmallTalk has been a faboulous book called "SmallTalk/V
DOS:  Tutorial and Programming Handbook".  It was published in 1992 but
it gets away, for the most part, from the pretty graphics and the
"modern day tutorial" driven books like the Dolphin SmallTalk
Companion.  Instead, it tackles the code head on, given it does utilize
comparisons between Pascal and SmallTalk.  I haven't touched C# yet
because of its close ties to Java.  I am pretty much anti-Java because
of all of the overhead and the slowness of execution.  I am seeing
SmallTalk runs circles (in my opinion) around Java even though it's
VM-based.  I'm starting to like it though and glad I chose it even
though its been tough.

David

> "The introduction of so-called object-oriented features (C++) into a
> non-object oriented language (C) was a fundamentally bad idea and set
> the whole software industry back 10 (now 25) years." Discuss.

The issue with C++ is you _have_ to use switch statements somewhere. Whether
that is in some factory method, somewhere a decision has to be made about
the object that needs to be created, and C++ has no concept of reflection
(that I know of), so I can't see a design that _easily_ enables some sort of
factory method without using a switch statement.... In Smalltalk you have
numerous ways of dealing with it..

- An IdentityDictionary using symbols/strings/codes as keys, and constructor
blocks (or Classes) as values

- A method that searches Class subclasses issuing some sort of test to find
a class that should be instantiated (Object allSubclasses do: [ :ea | (ea
handles: someCode) ifTrue: [ ^ea new ] ])

Has anyone come up with a solution to the problem in C++? We had a
programmers meeting the other day, the discussion was type safety, and a
comment in one of the coding standards books was "Prefer polymorphism to
type switching", but at some point you have to do it. It is an unfortunate
evil...

I dunno, these past couple of months working in C++ has just made me love
Smalltalk even more.

Andy,

I still like C++, its useful in a lot of low-level ways that
unfortunately SmallTalk, Java, VB, Python, COBOL, or any other language
with the exception of Assembly can never do.  Playing devil's advocate,
I see OO in a bad light sometimes.  It seems to me that languages such
as Java, Delphi, and to some extent VB are being marketed and pushed
heavily because it's a way for the software industry to hire developers
at much lower pay rates, or possibly making it easier to outsource.  I
see eventually when a software developer could be anyone out of high
school, which is already the case in some sense, and ultimately the
only well-paying wages will be software designers.  The Software
Engineering program to some extent is trying to engrain our minds with
the concept that Requirements Management and Software Design through
UML are better jobs than coding and we should come out of the SE
program looking for those types of jobs rather than Software
Development positions.  Although OO is well-organized and easy to grasp
with one glance at the code, I still enjoy writing C++ which not
everyone can understand and ultimately makes me a more valuable
developer than an OO language which is basically english.

David B.

Andy Bower wrote:

> "The introduction of so-called object-oriented features (C++) into a
> non-object oriented language (C) was a fundamentally bad idea and set
> the whole software industry back 10 (now 25) years." Discuss.

Not only is there "no silver bullet", but silver-plated bullets don't work so
well either ;-)

    -- chris

On 23 Sep 2005 08:12:43 -0700, David B <[hidden email]> wrote:

> Although OO is well-organized and easy to grasp
> with one glance at the code, I still enjoy writing C++ which not
> everyone can understand and ultimately makes me a more valuable
> developer than an OO language which is basically english.

ok. Then take just "one glance" at the MVP framework in Dolphin Smalltalk
and explain how it works.

Do *not* look at the available documentation or comments, just go by the code.

BTW, valuable is not the same as useful.

s.

David,

> I am seeing
> SmallTalk runs circles (in my opinion) around Java even though it's
> VM-based.  

Just curious: "run circles" in what sense?  Productivity, execution
speed?  If the latter, it might be slightly unfair if the particular JVM
is a piece of junk, but it might also be because the Smalltalk code is
simply designed better than the statically typed competition.
Algorithmic improvements often trump line-by-line speed.  When that is
not the case or does not go far enough, one can always compile something
into a DLL to get the best of both worlds.


 > I'm starting to like it though and glad I chose it even
> though its been tough.

It gets easier.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Sean,

> The issue with C++ is you _have_ to use switch statements somewhere. Whether
> that is in some factory method, somewhere a decision has to be made about
> the object that needs to be created, and C++ has no concept of reflection
> (that I know of), so I can't see a design that _easily_ enables some sort of
> factory method without using a switch statement.... In Smalltalk you have
> numerous ways of dealing with it..

True to a point.  Actually, I have been able to do some table-based work
that wasn't too horrible.  However, it might be true that to make it
work one needs macros and/or function pointers.

I have also encountered some runtime type info in C++ that again wasn't
too horrible.  How's that for an endorsement? :)


> Has anyone come up with a solution to the problem in C++? We had a
> programmers meeting the other day, the discussion was type safety, and a
> comment in one of the coding standards books was "Prefer polymorphism to
> type switching", but at some point you have to do it. It is an unfortunate
> evil...

Another thing you might try is static member functions; they do not take
a this pointer, so they act a lot like normal functions, and yet they
have some connection with their class.  You might be able to put them by
address in a map and get around some of the trouble.  That said, I agree
that closures and classes as objects is a much nicer way to handle things.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

IMHO I think that the best way to avoid switch is with polymophism, not
with an equivalent structure. In most cases there is a way to solve
problems without having to use IF or SWITCH. Using the Smalltalk
equivalents like ifTrue:, dictionaries or reflection is almost the same
thing. I mean, that there is a way to put that behavior in classes and not
in a control-flow sentence. In that way the code is not "asking", but is
about saying.
In fact we could say there is a master switch in Smalltalk, and that one
occurs in the VM, in the interpreter and in the late binding
architecture.

Diego

"David B" <[hidden email]> wrote in message
news:[hidden email]...
well, you just start using the Dolphin, and you'll get hooked given time :)

Regarding languages I must say I appretiate C much, much more than C++ , to
the extent where for C I see a clear uses (as sort of nowdays portable high
level assembler), but for C++ - not really. It is way too easy to make
mistakes, dangerous mistakes. I see a C++ as Doberman dog that has been
heavilly malested as a puppy. You can simpatise and feel for the beast, but
you can not put a trust into it that it will not bite you when you turn your
back.

Btw, it is written Smalltalk, not SmallTalk

rush
p.s. ok, I know that I am last one who has a right to make a spelling
suggestion on this group .. :)
--
http://www.templatetamer.com/
http://www.folderscavenger.com/