Python from Wise Guy's Viewpoint

[Pascal Costanza]

Fergus Henderson wrote:

> Pascal Costanza <costanza at web.de> writes:
> 
> 
>>- The important thing here is that the EMLOYED mixin works on any class, 
>>even one that is added later on to a running program. So even if you 
>>want to hire martians some time in the future you can still do this.
> 
> 
> What happens if the existing class defines a slot named "salary" or "company",
> but with a different meaning?  Are slot names global, or is there some sort
> of namespace control to prevent this kind of accidental name capture?

Sure, that's what Common Lisp's packages are there for. Define the 
EMPLOYED mixin in its own package - done! You won't ever need to worry 
about name clashes.

> Anyway, regarding how to write this example in a statically typed
> language: you can do this in a quite straight-forward manner,
> by just keeping a separate table of employees.

Yuck.

> 		static void test_employed() {
> 			class Person {
> 				public String name;
> 				Person(String n) { name = n; }
> 			};
> 			Person joe = new Person("joe");
> 			System.out.println("-> hire joe");
> 			hire(joe, 60000);
> 			System.out.println("name: " + joe.name);
> 			System.out.println("class: "
> 					+ joe.getClass().getName());
> 			Employee e = (Employee) employees.get(joe);
						^^^^^^^^^^^^^^^^^^
This part is not domain-specific, but shows that your abstraction leaks. 
I.e. the client of your interface has to remember how the employee 
abstraction is implemented in order to use it correctly.

In my original example, I was able to just call (company joe) and 
(salary joe) (or, in Java syntax, this would be joe.salary and 
joe.company). I.e., I don't have to know anything about the internal 
implementation.

You can't implement unanticipated optional features in a statically 
typed language that doesn't involve leaking abstractions.

> As you can see, there's no need here for dynamically changing the types of
> objects at runtime or for creating classes at runtime.  But you can employ
> Martians or any other object.

Sure. You also don't need functions and parameter passing. You also 
don't need GOSUB and RETURN. So why don't we just program in assembler 
again?

> This example makes use of one dynamic cast; that's because the Java
> type system doesn't support generics / parametric polymorphism.  It would
> be a little nicer to do this in a language which supported generics, then
> we could use `Hashtable<Object, Employee>' rather than just `Hashtable',
> and there wouldn't be any need for the dynamic cast to `(Employee)'.

I would still need to remember what features happen to be kept external 
from my objects and what not.


Pascal

P.S.: Your implementation of default_company doesn't match mine. Yours 
is not dynamically scoped. But maybe that's nitpicking...