Support for some kind of software (class) interfaces ?

[marten]

Another wish I have - and what is growing more and more I work with other system:

Are there any ideas or plans to support some kinds of interfaces for classes ?


Marten

[Eric Clayberg]

Are there any ideas or plans to support some kinds of interfaces for classes ?

If you mean Java-style interfaces, I imagine that the answer is "No".

Given the dynamic nature of Smalltalk typing, why would you want them?

Is this something you see in any other mainstream Smalltalk (like VisualWorks or Dolphin)?

[marten]

Are there any ideas or plans to support some kinds of interfaces for classes ?

If you mean Java-style interfaces, I imagine that the answer is "No".

Given the dynamic nature of Smalltalk typing, why would you want them?

Is this something you see in any other mainstream Smalltalk (like VisualWorks or Dolphin)?

Though lots of people hate the composition-/interface editor, I like them more and more (even regarding the problems they produce - initially I did all my work with the WindowBuilder, but now I try to work more and more with the original GUI stuff). This may be due to the fact, that I mostly have done C# programming in the last three years and I like the idea of defining interfaces more and more.

This may be also related to the fact, that all modelling tools (also the old original VAST Designer) work by defining interfaces - and if a language does not support it, this IS strange.

The interface editor IS some kind of doing interface definitions (also with typing), but it is limited ...

And on the other hand: actually all Smalltalk developers do programming by implementing interfaces - but the system simply do not support them. We have to create "method categories" and work with them to manage what is actually missing.

When writing methods most of the people assume, that the parameters of that method support several selectors (making an interface) and use these selectors within the method.

It should be possible to give the compiler a hint about these interfaces and it then can tell me, if the selectors I use are part of that interface.

Interfaces are also the reason, why the system can build "quick forms", which is one of the few wizards within this system.

I think it might be difficult to extend the old system (due to compatibility reasons) - but I would like to see more "domain-logic" support and this can only be done by a more formal approach (e.g. defining interfaces).

Hope, that this posting made some points clearer ... but I notice how the productivity in other languages increases and this is simply because the system itselfs knows more about there datatypes used in the program.

I do not want to change the dynamic typing of Smalltalk or reduce the interactivity of any Smalltalk system - but an interface system as a help system. This IS a pretty good way of writing software.

Marten

[jtzecher]

I tend to side with Eric on this subject. I don't really buy into the benefit of adding interfaces to Smalltalk. You said that "[...]I notice how the productivity in other languages increases[...]" when interfaces are used. I agree with that but not with your reasons. Productivity increases because it makes the other languages possible to use. By allowing classes to implement an interface, you can then define a variable to be an Interface rather than having to finagle the class hierarchy so you can assign some abstract class or just using Object. The interfaces are there to allow you to get around those constraints of the strong typing. This is unnecessary in Smalltalk so I believe the productivity gains would be minimal. I've been using Smalltalk since 1993 and one phrase that has been conspicuously absent from my thoughts is "Gee, a JAVA style interface would come in real handy about now".

[marten]

The interfaces are there to allow you to get around those constraints of the strong typing.".

I do not think, that interfaces have very much to do with strong typing.

Interfaces (for me) are the public definition of the public API of an object. VAST already does something like this (as I mentioned) and yes of course it is very often mentioned together with types.

Interfaces are the base for nearly all large software systems - some might call it API, some might call it mathods category. The VAST development group had someting like this in mind, when they created the interface editor and I also see a much larger interface thinking in the SmalltalkServer (SST) package.

Smalltalk programming is based on interface programming - but the people use the IDE, method categories or any other informal method - because the IDE does not support it.

You think in interfaces, otherwise all your code would throw a "does not understand" everwhere everytime.

Perhaps one has to wait for the various projects in Squeak, which addresses the problem already ...

Marten

[Eric Clayberg]

Perhaps one has to wait for the various projects in Squeak, which addresses the problem already

What does Squeak do?

If Interfaces become popular in other Smalltalk dialects, that would certainly make it more interesting for us.

[marten]

Perhaps one has to wait for the various projects in Squeak, which addresses the problem already

What does Squeak do?

If Interfaces become popular in other Smalltalk dialects, that would certainly make it more interesting for us.

One small tool in that direction may be SmallInterfaces (for VAST) and another interesting direction is "Traits" - but that has only indirect something to do with interfaces.

[Eric Clayberg]

One small tool in that direction may be SmallInterfaces (for VAST) and another interesting direction is "Traits" - but that has only indirect something to do with interfaces.

BTW, I should point out that we are always appreciative of user-suipplied goodies and code contributions.

One of the fastest ways to get a specific new feature added to VAST is to send us the code.

Anything we receive will be evaluated and either added to the base or to the goodies download page.

[Bob Nemec]

We've implemented an 'interface spec' on our domain classes which we use to drive generic attribute views and data validations. It's like a light version of the VA Parts interface (we use WindowBuilder for the UI; no Parts). I can see how something like that would be useful, especially for large applications.

Personally, I like the Strongtalk approach: an optional type check. Eric, have looked at Strongtalk? Any thoughts on porting it to VA?

[marten]

We've implemented an 'interface spec' on our domain classes which we use to drive generic attribute views and data validations.

Have you any documents about that - actually I'm trying to finish my modelling tool and source generator tool in 2007 and I'm looking for ideas you it could look like.

Actually I would like to know, what you think it should contain....

Marten

[Bob Nemec]

Sure... at the risk of exposing code that others may ridicule.

We have two class methods, #accessorSpec and #editPolicySpec, both are arrays of arrays (we used the GemStone #replicationSpec as a model).

#accessorSpec defines public attributes, get and set methods and type information. It's used for model verification (checks for bad links) and to support the generic UI, among other things. The #editPolicySpec maps a UI component to each attribute.

For example, let's see how #name would be used (I've removed some date indexing and permission noise from the details)...

accessorSpec
"#( ... ('public name' 'get method' 'set method' 'type' 'description' ) ... )
^#(('Name' #name #name: 'String' 'Name of this object'))

editPolicySpec
"#( ... (name accessorName editPolicyMethod) ... )
^#(('Set: Name' 'Name' #editPolicyForString))

editPolicyForString
^self textEditPolicyClass new

If the attribute is a collection, we store the type as a two element array: #(Collection class, element class), so we have things like ('Dictionary' 'NcmCalendar') and ('Collection' 'NcmCurrency').

The edit policy is used to render a new update widget when a cell is selected in a WkTableWidget widget. The XmNbeginEditCallback callback sends #beginEditValue:clientData:callData: where we set the callData editPolicy: to the new edit policy instance.

We have edit policies for drop down lists, text, dates, list prompts, spin buttons, numbers, etc.

We've used this framework code for about seven years now. Works well enough for us.