A couple of Questions

Hello All,

Could anyone please help me with the following queries:

1. Is there a way to create objects dynamically when all you have is the
name of the class as a string? Here is a brief Delphi example to try an
illustrate what I mean:

function Factory( const className : string ) : TPersistent;

  var
    cls : TPersistentClass;

begin
  cls := GetClass( className );
  if assigned( cls ) then
    // result is var that is auto declared with same type as func
    // function result is passed out via result a-la eiffel
    result := cls.Create;

end;

2. I was looking at the comment in Object>>isKindOf:. It says that: "is-
kind-of tests are bad practice and that you should test to see if an
object provides a particular protocol". Why is this and how do you test
to see if an object provides a protocol?

3. Am I right in assuming that Protocols are like interfaces in other
languages like Java, Delphi & C#? If so, how do you use them? In the
languages mentioned objects implementing an interface can be passed to
Methods or routines that expect the relevant interface or assinged to
interface variables. With Smalltalk being typeless and not having any
casting (that I know of) how does it take advantage of this
functionallity?

Thanks

regards

Barry Carr
Ixian Software Components Ltd,
Blairgowrie,
Perthshire,
Scotland

Barry Carr arrakis.clara.net> <barry@<nospam> wrote in message
news:Xns9222E7AB64D64barryarrakisclaranet@158.152.254.72...
> 1. Is there a way to create objects dynamically when all you have is the
> name of the class as a string? Here is a brief Delphi example to try an
> illustrate what I mean:

"Get a reference to the String class.  Error handling should be added if
this could fail."
theClass := (Smalltalk bindingFor: 'String') value.
obj := theClass new.

> 2. I was looking at the comment in Object>>isKindOf:. It says that: "is-
> kind-of tests are bad practice and that you should test to see if an
> object provides a particular protocol". Why is this and how do you test
> to see if an object provides a protocol?

It may be considered bad because the dynamically typed nature of Smalltalk
means you may have different classes at different locations in the class
hierarchy that can be used interchangeably.  This would break an isKindOf:
test unless they shared the class you were testing for as a parent.  It is
also not generally a good idea to have too many "type tests" regardless of
the technique in one's code.  Extensive use could be a symptom of procedural
logic and a poorly designed object structure.  It may mean that some context
specific logic is in the wrong place.

"Return all the protocols officially supported by String"
String allProtocols.
"Does String officially support the protocol?"
String conformsToProtocol: 'sequencedCollection'.
"Does String happen to implement all the methods required by the protocol?"
String canUnderstandProtocol: 'sequencedCollection'.
"Does String support the do: message?"
String canUnderstand: #do:.

> 3. Am I right in assuming that Protocols are like interfaces in other
> languages like Java, Delphi & C#? If so, how do you use them? In the
> languages mentioned objects implementing an interface can be passed to
> Methods or routines that expect the relevant interface or assinged to
> interface variables. With Smalltalk being typeless and not having any
> casting (that I know of) how does it take advantage of this
> functionallity?

I believe that protocols are a Dolphin specific feature.  I tend to think of
protocols as mostly for documentation purposes, though as the previous
example code illustrates protocols can be used for improved type context
based decision making.  Dolphin does not enforce protocols in your code
unless you use them for checks as shown above.  You can look at senders of
conformsToProtocol: to see how it is used in the base system.  You can see
the interface used to maintain Protocols on the Tools/Protocol Browser menu.
To understand the value of the protocol implementation in Dolphin look at
the gettableStream protocol.  You will see the expected Stream subclasses,
but you will also see IStream (which is in a different part of the class
hierarchy),  because it can respond to the set of gettableStream messages.
This makes it easy to see and test that an IStream and a ReadStream might be
used interchangeably.

Chris

> "Get a reference to the String class.  Error handling should be added if
> this could fail."
> theClass := (Smalltalk bindingFor: 'String') value.
> obj := theClass new.

Andy Bower recently posted a nice suggestion for this in c.l.s -

x := Smalltalk at: #String ifPresent: [:arg | arg new]

If the class exists then x will contain a new instance but will be nil if
the class doesn't exist.

Regards
    Ian

Hi Chris,

Thanks for your help. That's cleared a lot up for me.

Cheers

Barry

Hi Ian,

Excellent, thanks for this.

Cheers

Barry
 
"Ian Bartholomew" <[hidden email]> wrote in news:piZK8.2824
$xU5.332365@wards: