gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnue-dev] Halloween 3: Business Module Strategy


From: Reinhard Mueller
Subject: [Gnue-dev] Halloween 3: Business Module Strategy
Date: 03 Nov 2002 11:28:17 +0100

And the story continues...

A major point of Appserver is to manage business modules. Here is the
try of a definition of a module:

* a module is a group of class definitions that logically belong
together
* a module B can extend a class that was introduced by another module A,
if that is the case, we say that module B depends on module A
* two modules B and C can extend a class that was introduced by a third
module A; this must be possible without communication between the
authors of B and C.
* for that reason, every module has its own namespace.


Our strategy:
-------------

For example, we have:

module Base
  class Customer
    property Name
    property Street

module Barber (requires Base)
  extends Base_Customer
    property Color (means the hair color)
    property Length (means the hair length)

module Cardealer (requires Base)
  extends Base_Customer
    property Color (means the car's color)
    property Name (means the car's name)

Name clashes like in the above can't be avoided in distributed
development, because
a) the author of the Barber module doesn't know the author of the
Cardealer module, but my friend is a barber that sells cars and wants to
install both modules.
b) the author of the Base module doesn't know the author of the
Cardealer module and unluckily introduced the property "Name" in the
Base Customer definition long after this identifier was taken by the
Cardealer module.
Of course for b), the author of the Cardealer module could change his
definition as soon as he sees the change in the Base module, but that's
not a good solution.

The better solution is fully qualified names.

Every identifier (class name, property name, procedure name) can be
prefixed by the module name to fully qualify it.
Code is run in a specific module context, which is by default the module
that defines the code. Identifiers defined outside the module _must_ be
fully qualified, identifiers defined in the current module context _may_
be fully qualified, but they need not.
The module name is separated from the identifier by an underscore (_).
This impiles that the underscore is not a valid character in
identifiers.

For example, if the current context is "Cardealer", and c was an object
of type Customer, then
c.Color or c.Cardealer_Color refers to the car's color
c.Barber_Color refers to the hair color
c.Name or c.Cardealer_Name refers to the car's name
c.Base_Name refers to the customer's name
c.Street is invalid
c.Base_Street refers to the customer's street

The advantage of using the underscore as the separator is that Base_Name
is still a valid python identifier, while, for example, Base:Name or
Base::Name would not be.

More will come after lunch...

Thanks,
-- 
Reinhard Mueller
GNU Enterprise project
http://www.gnue.org

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


reply via email to

[Prev in Thread] Current Thread [Next in Thread]