Re: Python from Wise Guy's Viewpoint
Fergus Henderson wrote:
[color=blue]
> Pascal Costanza <costanza@web.d e> writes:
>
>[color=green]
>>- 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.[/color]
>
>
> 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?[/color]
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.
[color=blue]
> 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.[/color]
Yuck.
[color=blue]
> static void test_employed() {
> class Person {
> public String name;
> Person(String n) { name = n; }
> };
> Person joe = new Person("joe");
> System.out.prin tln("-> hire joe");
> hire(joe, 60000);
> System.out.prin tln("name: " + joe.name);
> System.out.prin tln("class: "
> + joe.getClass(). getName());
> Employee e = (Employee) employees.get(j oe);[/color]
^^^^^^^^^^^^^^^ ^^^
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.
[color=blue]
> 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.[/color]
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?
[color=blue]
> 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<Obje ct, Employee>' rather than just `Hashtable',
> and there wouldn't be any need for the dynamic cast to `(Employee)'.[/color]
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...
Fergus Henderson wrote:
[color=blue]
> Pascal Costanza <costanza@web.d e> writes:
>
>[color=green]
>>- 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.[/color]
>
>
> 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?[/color]
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.
[color=blue]
> 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.[/color]
Yuck.
[color=blue]
> static void test_employed() {
> class Person {
> public String name;
> Person(String n) { name = n; }
> };
> Person joe = new Person("joe");
> System.out.prin tln("-> hire joe");
> hire(joe, 60000);
> System.out.prin tln("name: " + joe.name);
> System.out.prin tln("class: "
> + joe.getClass(). getName());
> Employee e = (Employee) employees.get(j oe);[/color]
^^^^^^^^^^^^^^^ ^^^
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.
[color=blue]
> 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.[/color]
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?
[color=blue]
> 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<Obje ct, Employee>' rather than just `Hashtable',
> and there wouldn't be any need for the dynamic cast to `(Employee)'.[/color]
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...
Comment