Velocity Reviews - Single Class Object Model API, an exercise in style

On 30 mai, 18:27, markspace <-@.> wrote:
> On 5/30/2012 12:45 AM, micha wrote:
>
> > * * * The atoms of SCOM semantic networks are RDF-like triples (Subject
> > --Predicate--> *Object).
> > * * * In SCOM, all 3 parts of the triple are 'It' instances
>
> Could you give some examples where this is useful? *Show us some code
> that implements, say, an HTTP request service and a Swing MVC pattern.
> Then tell us why your way is better than the existing frameworks/pattern.
>
> > * * * - by overriding 'evaluate' method in subclasses of 'It'
>
> I don't like frameworks that jam all their functionality into one
> method. *Method names are important parts of a projects documentation,
> and you lose that if everything is "evaluate."
>
> > C#/C++) but instead dynamically
> > * * * created at runtime (much like classes described by SemanticWeb
> > Ontology language: 'Owl')
>
> You might want to explain what this actually means. *I doubt most
> programmers are familiar with Owl. *I'm certainly not.
------------------------------------------------------
Hello markspace

First, let me thank u for answering to my post. Also I would like to
highlight that this project
is only at it's very beginning (that's why I'm seeking feedback,
ideas, critics even 'thats's
bullshit'). Once that said, I will try to reply to the issues that u
raised:
.................................................. ..........................
> Could you give some examples where this is useful? *Show us some code
> that implements, say, an HTTP request service and a Swing MVC pattern.
> Then tell us why your way is better than the existing frameworks/pattern.
.................................................. ..........................
Let me remind that it is an exercise in style more than anything
else. The idea is not to be better
than existing frameworks but instead to try 'another path' which
is:
- the semantics of an application could be fully described at
runtime level rather than buildtime
- SCOM is strongly influenced by Semantic Web (or at least my
understanding of how this new paradigm
could change the way we code applications...).
- Semantic Web, uses Semantic Networks to represent knowledge of a
given business domain.
- These semantic networks may contain objects at 3 levels of
modeling (like in UML, in which there
is 4 levels in fact),
3 levels of Model:
- User Model (instances of business domain classes)
- Model (business domain classes)
- Meta Model (metaclasses which business domain classes are
instance of)

.................................................. ..........................
> > * * * - by overriding 'evaluate' method in subclasses of 'It'
>
> I don't like frameworks that jam all their functionality into one
> method. *Method names are important parts of a projects documentation,
> and you lose that if everything is "evaluate."
>
> > C#/C++) but instead dynamically
> > * * * created at runtime (much like classes described by SemanticWeb
> > Ontology language: 'Owl')
>
> You might want to explain what this actually means. *I doubt most
> programmers are familiar with Owl. *I'm certainly not.
.................................................. ..........................
SCOM is very 'low level' semantics (from a buildtime point of view)
and it's design intent
is to be agnostic (by not foreseeing how it could be used and for
what purpose).

Thus the API is 'fanatically' minimalist (only 'evaluate()'). But
that doesn't mean that there
is no semantics, it's only that semantics are no more in the source
code of the SCOM API but
instead in the runtime semantic network of 'It' instances ('It' is
the single class of SCOM API).

'It' API allows to create:

1. Runtime Classes (by means of helper factory method It.NewClass)
2. Instances of these runtime classes (by calling helper factory
method It.New with a runtime class created in 1.)

These Runtime Classes are inspired from another paradigm called
'Adaptative Object Model', which
is to define the Object Model at runtime (instead of buildtime in
'standard' OOP languages like C++/C#/Java)

These classes are instance of a 'native metaclass' (called 'Class',
it is created in a default Singleton
It instance called 'Environment', this is similar to the 'image' in
Smalltalk)
see: http://en.wikipedia.org/wiki/Smallta...wiki/Smalltalk

Then you may dynamically add 'facets', which may be implement
either:
- a property/attribute (e.g: 'motor' in following code sample)
- a method (e.g: 'ItSuccessorF' in following code sample)
- the facet value must be an instance of an It subclass which
overrides 'evaluate' (e.g: ItSuccessorF class)

e.g: here is an example in 'Tutorial1' sample
(scom.tutorials.tutorial1, https://github.com/terimakasi/scom):

It voiture_class_it = NewClass("Voiture")
.putFacet("motor", New("rolls royce"))
.putFacet(ItSuccessorF.BASENAME,
New(K_FUNCTION, "successor", ItSuccessorF.CLASS_NAME));

It ma_voiture = New(voiture_class_it);
Print("successor of '1': " +
ma_voiture.getFacet(ItSuccessorF.BASENAME).evaluat e(New(1)));

which outputs the following at runtime (demonstration of
a 'method call'):

successor of '1': 2

Now let's see of SCOM provides 'reflection' capability: the
ability for instances to self-describe
(thus to document the application as well and more than that
at runtime, with the runtime semantic
network whose structure and values are completely defined by
application configuration files,
events (e.g: user interface), etc...)

Here is an example of how to use reflection:

It voiture_class_it = NewClass("Voiture")
.putFacet("motor", New("rolls royce"))
.putFacet(ItSuccessorF.BASENAME,
New(K_FUNCTION, "successor", ItSuccessorF.CLASS_NAME));
It ma_voiture = New(voiture_class_it);
Print(ma_voiture);

which outputs the following at runtime:

voiture1
ItSuccessorF: successor
class: Voiture
moteur: rolls royce
name: voiture1

Moreover, by using the optional parameter
'WITH_UNLIMITED_DEPTH', the output shows facet's of facets
recursively (when facet is an instance, it's class is
described also):

It voiture_class_it = NewClass("Voiture")
.putFacet("motor", New("rolls royce"))
.putFacet(ItSuccessorF.BASENAME,
New(K_FUNCTION, "successor", ItSuccessorF.CLASS_NAME));
It ma_voiture = New(voiture_class_it);
Print(ma_voiture, WITH_UNLIMITED_DEPTH);

voiture1:
ItSuccessorF: successor
class: Voiture
Voiture:
class: Class
Class:
superclass: Class
count: 1
new: Class
class: Class
name: Class
count: 1
ItSuccessorF: successor
moteur: rolls royce
new: Voiture
superclass: Object
Object:
class: Class
Class:
superclass: Class
count: 1
new: Class
class: Class
name: Class
count: 0
value: NIL
superclass: Object
new: Object
name: Object
name: Voiture
moteur: rolls royce
name: voiture1

Because 'It' is very 'atomic', even writing an 'ultra-naive' sample
like adding 2 numbers is
much more verbous than it should be (see 'Test_Add' in
scom.samples.arithmetic).
But that's not the point because SCOM allows to implement 'real'
applications as well.
The verbosity issue is something I have started to scratch my head
on: SCOM API is like a
'machine language / assembler / bytecode' (and I guess it should be
written in Bytecode instead
of Java to perform realistically)
Thus SCOM users would benefit from a 'code generator'. Now you may
say that I reinvent the wheel
because it's exactly what compilers do from decades ago...

BUT there is a huge difference, because with SCOM, the 'runtime
object model' is unified (like
'Meta Object Protocol' in Lisp), thus allowing runtime tools like
'debugger' to operate no more
on 'static object model' (Java) but instead on 'runtime object
model' (e.g: changing a class at
runtime which is not possible with Java or at least not without a
strong expertise of 'inside JVM')