Module

[Will Cook]

There are pluses and minuses to using the word 'module' in the definition of object.

+ it has a nice parallel with the definition of functional programming: first-class function versus first-class module

     (note that it is always understood that first-class functions are "late bound", so there is no need to qualify that in the FP definition)

+ it is short and well-known to every developer+ as an example, it fits very nicely with the historical development of Modula-2 to Modula-3   

+ Scala also seems to equate "object" and "first-class module"

+ It already includes the idea of encapsulation/hiding, so we don't have to include that in the definition of object

+ It will really annoy the ML people :-)

- "module" itself is not well-defined

- It has many complex connotations, especially for PL experts

What to do?

[Will Cook]

                    Hi everyone,

Resending a version of this.. now that more people are here.

The more I think about it, the more I like using "module" in the definition (if I can convince you is ok).

Positives:
+ It is good because module is a well-known concept that everyone understands its *benefits*
    Then adding more features (polymoprhism + first-class) it is natural to expand those benefits
+ It has a nice parallel with the definition of functional programming: first-class function versus first-class module

     (note that it is always understood that first-class functions are "late bound",

      so there is no need to qualify that in the FP definition. Nobody mentions this when criticizing
      message passing/late binding in OO)

+ as an example, it fits very nicely with the historical development of Modula-2 to Modula-3  

+ precedent: Scala also seems to equate "object" and "first-class module"
+ Module already includes the idea of encapsulation/hiding, so we don't have to include that in the definition of object
+ It will really annoy Bob Harper (Sorry.. i couldn't resist...but I only half mean this :-)

Negatives:

- "module" itself is not well-defined
- It has many complex connotations, especially for PL experts

- other?

--

William Cook
Associate Professor, Computer Science
University of Texas at Austin

[kevlin Henney]

I'm happy with the term module as it comes with a lot of existing meaning and precision that applies to objects and avoids the problematic connotations of other words that suggest units that represent groupings, such as component or bundle. All words have connotations, not all of which are helpful, but it is likely that module has fewer that need clarifying than most other existing terms or any made-up term.

A softer more descriptive, less definitional term, would be modular or modular concept, as in "an object is modular" or "an object is a modular concept".

Either way, it is a term that itself will require a definition to distinguish it from other interpretations of the word module, e.g., the confusing use in the Java community to use module to refer to a very large unit of deployment.

[James Noble]

> A softer more descriptive, less definitional term, would be modular or modular concept, as in "an object is modular" or "an object is a modular concept".

an object is encapsulated, or
an object encapsulates its implementation

Modules are not first class in most module systems.
Clemens Szyperski used to make a lot of this in his
"Component Software" books --- a component is
explicitly static, and is not first class.

James

[James Noble]

> + It has a nice parallel with the definition of functional programming: first-class function versus first-class module

algebra vs coalgebra?

(as Bart Jacobs the Elder would probably say)

I don't understand anywhere near enough category theory to actually make any sense of that!

James

[Kevlin Henney]

Hence why component is a word to avoid. Saying that an object is encapsulated is certainly true, but in some ways invites more questions than it offers answers.

Perhaps the clarification is to be found in your first sentence: objects are first-class modules.

Kevlin 

--
________________________

  Kevlin Henney
  +44 7801 073 508
  http://asemantic.net
  http://kevlin.tel
________________________

[James Noble]

On 13/07/2012, at 23:02 PM, Kevlin Henney wrote:

> Perhaps the clarification is to be found in your first sentence: objects are first-class modules.

Well that's William's version!

But I think - whether module or component or whatever - most of those
words imply something big, something heavyweight. Consider "process" vs "thread".
An object, conceptually, should be small and lightweight.

Think Gilad's "Modules as Objects in Newspeak". Apart from really being "Module as *Classes*",
he's saying big, heavy things (Modules) can be implemented with small, simple things (Classes).



It's interesting that both Alan Kay & the Scandinavians end up saying the same kind of thing:

- An object is a recursion on the idea of the computer itself.

- A program execution is a _physical model_...

James

[Kevlin Henney]

On 13 July 2012 12:14, James Noble <k...@ecs.vuw.ac.nz> wrote:

On 13/07/2012, at 23:02 PM, Kevlin Henney wrote:

> Perhaps the clarification is to be found in your first sentence: objects are first-class modules.

Well that's William's version!

Uh huh ;-)

 

But I think - whether module or component or whatever - most of those
words imply something big, something heavyweight.   Consider "process" vs "thread".
An object, conceptually, should be small and lightweight.

I'm not sure that's the implication I get, based on Parnas, Modula, Meyer, etc. When expressed in terms of data abstraction the implication of module has always been fairly small. When equated with deployable component it has tended to be larger.

The process versus thread distinction is also not consistent in scale when these concepts are viewed from a non-OS perspective, e.g., in Erlang.

It's interesting that both Alan Kay & the Scandinavians end up saying the same kind of thing:

 - An object is a recursion on the idea of the computer itself.

 - A program execution is a _physical model_...

I would say that supports the use of the term module :^)

So, an object is a first-class module, meaning that it is an encapsulation of operations, with implementation and state representation hidden, thus it is also a data abstraction.

Kevlin 

[James Noble]

On 13/07/2012, at 23:29 PM, Kevlin Henney wrote:

> So, an object is a first-class module, meaning that it is an encapsulation of operations, with implementation and state representation hidden, thus it is also a data abstraction.

yep. and then you just shorten that and say

> an object is first-class, and encapsulates operation implementation and state representation

J

[Kevlin Henney]

Which is concise, but may not situate objects as precisely in the world of concepts. For example, the subclause is also true of ADTs.

[James Noble]

On 13/07/2012, at 23:37 PM, Kevlin Henney wrote:

> Which is concise, but may not situate objects as precisely in the world of concepts. For example, the subclause is also true of ADTs.

ADT's aren't first-class. Add you'd still need to chuck a "polymorphic" in there too.

Now if you want to start talking about "the world of concepts" then you really should be more Scandinavian, and think about what Alan Kay meant when he says "a stack is not an object"...

James, who should go to bed!

[Kevlin Henney]

On 13 July 2012 12:40, James Noble <k...@ecs.vuw.ac.nz> wrote:

On 13/07/2012, at 23:37 PM, Kevlin Henney wrote:

> Which is concise, but may not situate objects as precisely in the world of concepts. For example, the subclause is also true of ADTs.

ADT's aren't first-class.

Indeed. However, first-class is an adjectival phrase and has to apply to something. First-class what? Hence why I'm comfortable with objects are first-class modules.

Add you'd still need to chuck a "polymorphic" in there too.

I think it is possible to define it such that polymorphism is a consequence of the definition rather than part of the definition itself. Just thinking aloud.

 

Now if you want to start talking about "the world of concepts" then you really should be more Scandinavian, and think about what Alan Kay meant when he says "a stack is not an object"...

Alan Kay says a lot of things. One often has to apply a filter ;-)