Artima Developer Spotlight Forum - Namespacey Programming

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Artima Developer Spotlight Forum
Namespacey Programming

30 replies on 3 pages. Most recent reply: Dec 12, 2007 1:21 PM by nes

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 30 replies on 3 pages [ « | 1 2 3 | » ]

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Namespacey Programming

Posted: Oct 12, 2007 8:31 AM

> No, it wouldn't be surprising if you're using Java. Java
> coders have grown accustomed to polymorphism swapping out
> method definitions.

Well, I think it's just as common in Python and other more smalltalk like languages. But yes, my primary language has been Java for a number of years.

I guess what I'm trying to say is that the only difference between the example where a function is passed to the method in scheme and an OO version where the method pulled from the object context is the implicit context of the object. They are really quite equivalent. There is a bit of knowledge required in the OO version in that unless that method is abstract, it's not readily apparent that you don't know exactly where that method came from.

That I see functional and OO paradigms as being related may indeed come from my Java experience. The reason being that because Java doesn't allow you to pass methods (ignoring reflection) to methods, the only way to create code equivalent to passing a method to a method is to use polymorphism. At some point it became clear to me (at least) that that's always what I am doing when I use polymorphism in Java: passing one or more methods to other methods.

I'm still a little dubious about the idea of polymorphic variables. Perhaps this is just ignorance on my part but unless you can access the variable as defined in the superclass in some way (e.g. 'super' in Java), it's no different than replacement even if the old variable is just hidden by a new declaration. I know that in at least one language there is little distinction made between a variable access and a method call so is that what you are referring to?

Michael Hobbs

Posts: 51
Nickname: hobb0001
Registered: Dec, 2004

Re: Namespacey Programming

Posted: Oct 12, 2007 9:58 AM

> I guess what I'm trying to say is that the only difference
> between the example where a function is passed to the
> method in scheme and an OO version where the method pulled
> from the object context is the implicit context of the
> object. They are really quite equivalent.

I don't think there's actually any disagreement here. In fact, in my original posting I mentioned that explicitly passing the namespace (i.e., collection of functions) as a parameter to a method would be a "functional" way of doing OOP.

> I'm still a little dubious about the idea of polymorphic
> variables. Perhaps this is just ignorance on my part but
> unless you can access the variable as defined in the
> superclass in some way (e.g. 'super' in Java), it's no
> different than replacement even if the old variable is
> just hidden by a new declaration. I know that in at least
> one language there is little distinction made between a
> variable access and a method call so is that what you are
> referring to?

I'm deliberately intermixing functions and variables when referring to polymorphism, since in functional programming languages there is no difference between the two. If Java had first-class functions, it could be possible to override a method by simply changing its value as if it were a variable.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Namespacey Programming

Posted: Oct 12, 2007 12:03 PM

> I don't think there's actually any disagreement here. In
> fact, in my original posting I mentioned that explicitly
> passing the namespace (i.e., collection of functions) as a
> parameter to a method would be a "functional" way of doing
> OOP.

You're right, there is no disagreement.

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Namespacey Programming

Posted: Oct 12, 2007 12:50 PM

I never found the dichotomy between OO and functional programming to be very solid. If you have modules, namespaces and multimethods what is so different in OO?

Is the following hypothetical language functional or OO?


Module asteroid
Struct asteroid ([int] mass, [3dimension] size) tags [asteroid, rock]
Define asteroid_init ()
Define collide([asteroid] x, [asteroid] y)
Define collide([asteroid] x, [spaceship] y)
Define set_dimension([asteroid, rock] x, [3dimension] size)
Define get_dimension([asteroid, rock] x)

Module spaceship
Struct spaceship ([int] maxspeed, [3dimension] size) tags [spaceship, vehicle]
Define spaceship_init()
Define collide([spaceship] x, [asteroid] y)
Define collide([spaceship] x, [spaceship] y)
Define set_dimension([spaceship] x, [3dimension] size)
Define get_dimension([spaceship] x)

Module vehicle
Define drive([vehicle] x)

Module main
From asteroid import *
From spaceship import *
From vehicle import *

brownrock=asteroid_init()
set_dimension(brownrock, (8,6,4))

reddwarf9=spaceship_init()
set_dimension(reddwarf9, (30,20,50))

drive(reddwarf9)
collide(brownrock, reddwarf9)
d=get_dimension(reddwarf9)

Michael Hobbs

Posts: 51
Nickname: hobb0001
Registered: Dec, 2004

Re: Namespacey Programming

Posted: Oct 12, 2007 1:35 PM

> Is the following hypothetical language functional or OO?

I didn't see any functions being used as first-class values, so I can't say if it's functional or not. But considering that function calls such as "drive(redwarf9)" and "collide(brownrock, reddwarf9)" don't return any values, it doesn't look very functional.

Also, there's not enough information in your example to determine if it's OO or not. It's not clear how it would resolve function calls. For example, what if you had defined collide([vehicle] x, [spaceship] y) and collide([spaceship] x, [vehicle] y) but not collide([spaceship] x, [spaceship] y), which one of the two would be invoked if you collided two spaceships?

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Namespacey Programming

Posted: Oct 15, 2007 8:08 AM

> > Is the following hypothetical language functional or
> OO?
>
> I didn't see any functions being used as first-class
> values, so I can't say if it's functional or not. But
> considering that function calls such as "drive(redwarf9)"
> and "collide(brownrock, reddwarf9)" don't return any
> values, it doesn't look very functional.
>
> Also, there's not enough information in your example to
> determine if it's OO or not. It's not clear how it would
> resolve function calls. For example, what if you had
> defined collide([vehicle] x, [spaceship] y) and
> collide([spaceship] x, [vehicle] y) but not
> collide([spaceship] x, [spaceship] y), which one of the
> two would be invoked if you collided two spaceships?

Let’s assume that functions are first class values and that functions can have side effects but they always return a value (at least null) that might get ignored. As far as the resolution order goes, make it left over right. Spaceship is defined as spaceship first so it would match on collide([spaceship] x, [vehicle] y). Would you consider the language strictly procedural then?

I don’t know if the example explains what I am trying to get at. To me the difference between Functional and OO doesn’t seem to be structs and functions versus objects with attributes and methods (those look like the same thing in pre and postfix notation to me).

Michael Hobbs

Posts: 51
Nickname: hobb0001
Registered: Dec, 2004

Re: Namespacey Programming

Posted: Oct 15, 2007 10:45 AM

> Let’s assume that functions are first class values and
> that functions can have side effects but they always
> return a value (at least null) that might get ignored. As
> far as the resolution order goes, make it left over right.
> Spaceship is defined as spaceship first so it would match
> on collide([spaceship] x, [vehicle] y). Would you consider
> the language strictly procedural then?

Okay, I think I see. Would it be fair to say then, that the tag of the first parameter defines a virtual class? That is, all the functions that have [spaceship] as their first parameter are essentially the "methods" of the spaceship object?

You're right in that multi-methods are another way to specify the polymorphism that we get in OO languages. It's interesting in that multi-methods don't require inheritance to work.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Namespacey Programming

Posted: Oct 15, 2007 4:07 PM

In the hypothetical language example we don't know if it's coincidental that the same word is used in different places or essential - 'spaceship' is a module, a struct, a tag and something in a function parameter list.

When 'spaceship' is followed by 'vehicle' in a struct tag list, we don't know what that says about 'vehicle' matching 'spaceship' in a function parameter list.

In a real language, Nice, if there's no relationship between 'vehicle' and 'spaceship' and we don't define the binary method

class Vehicle {
   void collide(Spaceship y){} // collide(v,s)
}
class Spaceship {}

void collide(Spaceship x, Vehicle y){} // collide(s,v)

void method(){
   let s = new Spaceship();
   let v = new Vehicle();
   collide(v,s);
   collide(s,v);
   collide(s,s); // not defined
}


~/tmp/testzone/spacey/test.nice: line 13, column 4:
No possible call for collide.
Arguments: (spacey.Spaceship, spacey.Spaceship)
Possibilities:
nice.lang.void collide(spacey.Spaceship x,spacey.Vehicle y)
nice.lang.void collide(spacey.Vehicle this,spacey.Spaceship y)
compilation failed with 1 error

(Note the 2 different ways to define collide - one inside a class definition with an implicit first parameter, and one outside a class definition with an explicit parameter.)

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Namespacey Programming

Posted: Oct 16, 2007 6:16 AM

> In the hypothetical language example we don't know if it's
> coincidental that the same word is used in different
> places or essential - 'spaceship' is a module, a struct, a
> tag and something in a function parameter list.
>
> When 'spaceship' is followed by 'vehicle' in a struct tag
> list, we don't know what that says about 'vehicle'
> matching 'spaceship' in a function parameter list.
>
>
> In a real language, Nice, if there's no relationship
> between 'vehicle' and 'spaceship' and we don't define the
> binary method

You are right my example is confusing in that respect. The use of the same word 'spaceship' is coincidental. The only thing that matters is the match of tag with function parameter. I thought that in the simplest sense it could be just a registry. Meaning I possibly have a parameter signature tags dictionary with pointers to functions. On invocation I search in the dictionary for a signature of the first tag for all structs passed as parameters, then search for one with the second tag of the last parameter and so on (depth first search).

Incidentally check out slide 9 of a presentation of Walter Bright and Andrei Alexandrescu on the future of the D language: http://s3.amazonaws.com/dconf2007/WalterAndrei.pdf

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Namespacey Programming

Posted: Oct 16, 2007 10:20 AM

nes wrote
> You are right my example is confusing in that respect. The
> use of the same word 'spaceship' is coincidental. The only
> thing that matters is the match of tag with function
> parameter.

What I found very confusing was when Michael Hobbs switched to an example of 'collide' with 'spaceship' and 'vehicle' - does 'tags [spaceship, vehicle]' imply a relationship between 'spaceship' and 'vehicle' that allows substitution of 'vehicle' for 'spaceship' in 'collide'?

In Java or Nice terms

class Vehicle {}
class Spaceship extends Vehicle {}

> I thought that in the simplest sense it could
> be just a registry. Meaning I possibly have a parameter
> signature tags dictionary with pointers to functions. On
> invocation I search in the dictionary for a signature of
> the first tag for all structs passed as parameters, then
> n search for one with the second tag of the last parameter
> and so on (depth first search).

These seem like are implementation details.

> Incidentally check out slide 9 of a presentation of Walter
> Bright and Andrei Alexandrescu on the future of the D
> language:
> http://s3.amazonaws.com/dconf2007/WalterAndrei.pdf

Interesting.

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Namespacey Programming

Posted: Oct 17, 2007 1:44 PM

> nes wrote
> > You are right my example is confusing in that respect.
> The
> > use of the same word 'spaceship' is coincidental. The
> only
> > thing that matters is the match of tag with function
> > parameter.
>
> What I found very confusing was when Michael Hobbs
> switched to an example of 'collide' with 'spaceship' and
> 'vehicle' - does 'tags [spaceship, vehicle]' imply a
> relationship between 'spaceship' and 'vehicle' that allows
> substitution of 'vehicle' for 'spaceship' in 'collide'?
>
> In Java or Nice terms

class Vehicle {}
> class Spaceship extends Vehicle {}

Yes something similar to that. Additionally to method resolution it would allows substitution, but I was assuming Spaceship would not automatically inherit any fields from vehicle. All structs tagged as vehicle just would have to already have all fields required for a implicit vehicle interface.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Namespacey Programming

Posted: Oct 17, 2007 5:51 PM

nes wrote
-snip-
> Additionally to method resolution it would allows substitution ...

Keeping those method definitions, and changing the class relationship

class Vehicle {}
class Spaceship extends Vehicle {}

void collide(Vehicle x, Spaceship y){} 
void collide(Spaceship x, Vehicle y){} 

...

~/tmp/testzone/spacey/test.nice: line 13, column 4:
Ambiguity for symbol collide. Possibilities are :
nice.lang.void collide(spacey.Spaceship x,spacey.Vehicle y)
nice.lang.void collide(spacey.Vehicle x,spacey.Spaceship y)
compilation failed with 1 error

Unless we wanted something special for collisions between Spaceships and Vehicles, or Spaceships and Spaceships, maybe we'd just say

void collide(Vehicle x, Vehicle y){}

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Namespacey Programming

Posted: Oct 18, 2007 1:21 PM

> nes wrote
> -snip-
> > Additionally to method resolution it would allows
> substitution ...
>
> Keeping those method definitions, and changing the class
> relationship

class Vehicle {}
> class Spaceship extends Vehicle {}
> 
> void collide(Vehicle x, Spaceship y){} 
> void collide(Spaceship x, Vehicle y){} 
> 
> ...
> 
> ~/tmp/testzone/spacey/test.nice: line 13, column 4:
> Ambiguity for symbol collide. Possibilities are :
> nice.lang.void collide(spacey.Spaceship x,spacey.Vehicle
> y)
> nice.lang.void collide(spacey.Vehicle x,spacey.Spaceship
> y)
> compilation failed with 1 error

>
> Unless we wanted something special for collisions between
> Spaceships and Vehicles, or Spaceships and Spaceships,
> maybe we'd just say

void collide(Vehicle x, Vehicle
> y){}

I don't quite understand why nice complains. I guess it doesn't want to choose based on rules that are too complex. If the first object was a Spaceship I would have chosen the first method over the second because a spaceship is more specific than a vehicle and I consider the first parameter more important than the second.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Namespacey Programming

Posted: Oct 18, 2007 4:26 PM

nes wrote
-snip-
> If the first object was a Spaceship I would have
> chosen the first method over the second because a
> spaceship is more specific than a vehicle and I consider
> the first parameter more important than the second.

I haven't checked, my guess is that all the parameters are regarded as equally important - dispatch on multiple parameters, not dispatch on parameter 1 then 2 then 3 ...

Carfield Yim

Posts: 32
Nickname: carfield
Registered: Sep, 2002

Re: Namespacey Programming

Posted: Oct 25, 2007 3:44 AM

I think Joe Armstrong also disagree about the concept of Domain Driven Development? He have present his own feeling about some aspect of languages, like state management, data dictionary, Data structure and functions ; I don't think there is right or wrong about his feeling.

However, as a developer growth in the "hype" of OO, I would think is revert and I think Erlang is very difficult to understand and maintain...

Flat View: This topic has 30 replies on 3 pages [ « | 1 2 3 | » ]

Previous Topic

Next Topic