Single Class Object Model - new release

[micha]

--------------------------------------------------------------
SCOM: Single Class Object Model
------------------------------
----- Programmer's Guide -----
------------------------------
www.terimakasi.com 28 may 2012 - 22:52
https://github.com/terimakasi/scom
--------------------------------------------------------------
1. Introduction
---------------
SCOM is a exercise in style with a 'constructivist' motivation. The
purpose is to design an Model Objet provided
as a Single class (!!), called 'It' (core/root class).

SCOM paradigm is founded on top of 3 'Design Intents':

a. Runtime Semantic Network
---------------------------
SCOM provides an easy and straightforward way to creatr 'semantic
networks' at runtime (much like XML DOM)
The atoms of SCOM semantic networks are RDF-like triples (Subject
--Predicate--> Object).
In SCOM, all 3 parts of the triple are 'It' instances
- 'Subject': is an It instance
- 'Predicate': is an unidirectional relation, it is called a
'facet'
- 'Object': is called a 'facet value'

b. Self evaluation instances
----------------------------
Inspired by functional programming (especially 'Lisp'). Thus
Application behavior is implemented:
- by overriding 'evaluate' method in subclasses of 'It'
- once a subclass implements a method, it could then be added to
an It instance as a 'behavioral facet'

c. Native Adaptative Object Model
---------------------------------
SCOM supports the AOM paradigm (Adaptative Object Model), where
business domain classes are not static like
'regular OOP languages' (e.g: Java, C#/C++) but instead
dynamically created at runtime (much like
classes described by Semantic Web Ontology language: 'Owl')

 

[Lew]

I believe "objet" is the French word, is it not?

as a Single class (!!), called 'It' (core/root class).

What do the exclamation points signify?

SCOM paradigm is founded on top of 3 'Design Intents':

a. Runtime Semantic Network

Meaning what, exactly?

---------------------------
SCOM provides an easy and straightforward way to creatr 'semantic
networks' at runtime (much like XML DOM)
The atoms of SCOM semantic networks are RDF-like triples (Subject
--Predicate--> Object).
In SCOM, all 3 parts of the triple are 'It' instances
- 'Subject': is an It instance
- 'Predicate': is an unidirectional relation, it is called a
'facet'
- 'Object': is called a 'facet value'

b. Self evaluation instances
----------------------------
Inspired by functional programming (especially 'Lisp'). Thus
Application behavior is implemented:
- by overriding 'evaluate' method in subclasses of 'It'
- once a subclass implements a method, it could then be added to
an It instance as a 'behavioral facet'

c. Native Adaptative Object Model
---------------------------------
SCOM supports the AOM paradigm (Adaptative Object Model), where
business domain classes are not static like
'regular OOP languages' (e.g: Java, C#/C++) but instead
dynamically created at runtime (much like
classes described by Semantic Web Ontology language: 'Owl')

How does this pertain to Java programming?

How will it help Java programmers?

 

[micha]

--------------------------------------------------------------
              SCOM: Single Class Object Model
              ------------------------------
              ----- Programmer's Guide -----
              ------------------------------ [snip]

I believe "objet" is the French word, is it not?

  as a Single class (!!), called 'It' (core/root class).

What do the exclamation points signify?

  SCOM paradigm is founded on top of 3 'Design Intents':

  a. Runtime Semantic Network

Meaning what, exactly?

  ---------------------------
     SCOM provides an easy and straightforward way to creatr 'semantic
networks' at runtime (much like XML DOM)
     The atoms of SCOM semantic networks are RDF-like triples (Subject
--Predicate--> Object).
     In SCOM, all 3 parts of the triple are 'It' instances
     - 'Subject':   is an It instance
     - 'Predicate': is an unidirectional relation, it is called a
'facet'
     - 'Object':    is called a 'facet value'

  b. Self evaluation instances
  ----------------------------
     Inspired by functional programming (especially 'Lisp'). Thus
Application behavior is implemented:
     - by overriding 'evaluate' method in subclasses of 'It'
     - once a subclass implements a method, it could then be added to
an It instance as a 'behavioral facet'

  c. Native Adaptative Object Model
  ---------------------------------
     SCOM supports the AOM paradigm (Adaptative Object Model), where
business domain classes are not static like
     'regular OOP languages' (e.g: Java, C#/C++) but instead
dynamically created at runtime (much like
     classes described by Semantic Web Ontology language: 'Owl')

How does this pertain to Java programming?

How will it help Java programmers?

Thanks for your answer Lew

- Yes there's a typo 'Objet' instead of 'Object', not a big deal

- Regarding the !! and 'semantic network' question, here's my answer:
!! is because an Object Model with a single class may seem foolish/
dummy/useless/stoopid but in fact it's may also be considered:
- as a creative challenge
- moreover as a way to show that it(s not mandatory that the
usefulness of an object model resideds in it's API (the default
assumption), but instead in the semantic network of instances that you
can build with it, that's the main idea within SCOM: it's instances
are easily assembled in a semantic network by using triples as the
semantic atom (Subject --predicayte--> Object, like RDF which is the
foundation of Semantic Web)

- The relation with Java is to highlight that Java has a buildtime/
static object model (instances are dynamic/runtime but classes are
static/buildtime) and that there is another paradigm called AOM
(Adaptative Object Model) where classes are dynamic too. SCOM is an
illustration that this paradigm can be implemented on top of Java thus
opening new possibilities which are not reachable with a static object
model

 

[micha]

Wouldn't it be easier and more convenient to just program in Common
Lisp from the get go? (The above just strikes me as an example of
Greenspun's tenth rule in action.)

Hello Leif

Thanks for the Greenspun's tenth rule (thought I matbe heard about it
long time ago but that's a nice piece of thinking to highlight for
sure)
Well, Lisp especially Common Lisp is pure in the intention not so much
in the facts: there's a huge number of functions in Common Lisp, not
all
absolutely legitimate to be in the core of a language, then there was
Scheme which seems to be a 'minimalist Scheme'. In fact all functional
languages share this property to leverage the expressiveness, now we
have functional (lambda calculus) in a wide variety of flavors even
some on JVM (Scala, Groovy, Clojure) or CLR (Clojure, F#)

BUT nevertheless Java has an unsurpassed firepower with tons of
libraries, frameworks and dialects, so it could be useful if only for
that reason (while Lisp developers have much more trouble to find
software components for their needs so they may find themselves
working hard to wrap a java component for Lisp instead of writing the
business domain code)

AND SCOM is not only about levererage of functional programming but
also:
- about Adaptative Object Model (which is also already native but more
in Smalltalk than in Lisp as Common Lisp is not an Object language
from the start but requires an extension layer (CLOS) to support
Object paradigm)
- and about Semantic Web paradigm, starting with semantic networks
described as triples by RDF/Owl:SCOM provides a simple and
straightforward mechanism (addfacet() method) to build such 'triple
based' semantic networks at runtime (like DOM is the runtime
data structure counterpart of an XML file)

NOW there is Scala which is both functional and Object BUT not a
purely interpreted metalanguage like Lisp (Lisp allows to define new
Languages with it's bootstrapping/dynamic syntax capabilities)

SO SCOM is not an attempt to do better than breakthrough languages
like Scala, it's only an attempt to show that within Java microcosm,
there's still ways to leverage expressiveness by adopting new
paradigms namely Adaptative Object Model, Semantic Web inspired
runtime data structures (not by extending Java with tons of new
features which address implementation needs without really adding
expressiveness or in the best case clearing out some inconsistencies,
like int vs Integer, [] vs ArrayList etc...)

 

[Robert Klemme]

BUT nevertheless Java has an unsurpassed firepower with tons of
libraries, frameworks and dialects,

But you don't want to use them because you just want to have a single
class, do you?

AND SCOM is not only about levererage of functional programming but
also:
- about Adaptative Object Model (which is also already native but more
in Smalltalk than in Lisp as Common Lisp is not an Object language
from the start but requires an extension layer (CLOS) to support
Object paradigm)
- and about Semantic Web paradigm, starting with semantic networks
described as triples by RDF/Owl:SCOM provides a simple and
straightforward mechanism (addfacet() method) to build such 'triple
based' semantic networks at runtime (like DOM is the runtime
data structure counterpart of an XML file)

NOW there is Scala which is both functional and Object BUT not a
purely interpreted metalanguage like Lisp (Lisp allows to define new
Languages with it's bootstrapping/dynamic syntax capabilities)

SO SCOM is not an attempt to do better than breakthrough languages
like Scala, it's only an attempt to show that within Java microcosm,
there's still ways to leverage expressiveness by adopting new
paradigms namely Adaptative Object Model, Semantic Web inspired
runtime data structures (not by extending Java with tons of new
features which address implementation needs without really adding
expressiveness or in the best case clearing out some inconsistencies,
like int vs Integer, [] vs ArrayList etc...)

I still did not get what the purpose of this exercise is. Why do you do
this? To what end?

Cheers

robert

 

[Lew]

SO SCOM is not an attempt to do better than breakthrough languages
like Scala, it's only an attempt to show that within Java microcosm,
there's still ways to leverage expressiveness by adopting new
paradigms namely Adaptative Object Model, Semantic Web inspired
runtime data structures (not by extending Java with tons of new
features which address implementation needs without really adding
expressiveness or in the best case clearing out some inconsistencies,
like int vs Integer, [] vs ArrayList etc...)

There is nothing inconsistent between 'int' and 'Integer', nor between
arrays and 'ArrayList' in Java.

Likewise there is nothing inconsistent between 'enum's and 'java.io.Reader'
implementations.

 

[micha]

SO SCOM is not an attempt to do better than breakthrough languages
like Scala, it's only an attempt to show that within Java microcosm,
there's still ways to leverage expressiveness by adopting new
paradigms namely Adaptative Object Model, Semantic Web inspired
runtime data structures (not by extending Java with tons of new
features which address implementation needs without really adding
expressiveness or in the best case clearing out some inconsistencies,
like int vs Integer, [] vs ArrayList etc...)

There is nothing inconsistent between 'int' and 'Integer', nor between
arrays and 'ArrayList' in Java.

Likewise there is nothing inconsistent between 'enum's and 'java.io.Reader'
implementations.

Yes it's inconsistent:
- because [] and ArrayList/Collections are 2 different ways to handle
vectors/lists (while there is only 1 in Python/Lisp/Perl
- because int is a primitive type (like in procedural languages)
while Integer are Objects (the bypass to put integers in a Collection
in fact)
instead all entities in Scala/Smalltalk are Objects (even
functions), and scripting language (Python/Perl/PHP/Lisp) provide lazy
typing and are thus
more consistent (even if at the price of more risk to write
erroneous code which language laziness will let go through)

 

[micha]

BUT nevertheless Java has an unsurpassed firepower with tons of
libraries, frameworks and dialects,

But you don't want to use them because you just want to have a single
class, do you?

AND SCOM is not only about levererage of functional programming but
also:
- about Adaptative Object Model (which is also already native but more
in Smalltalk than in Lisp as Common Lisp is not an Object language
from the start but requires an extension layer (CLOS) to support
Object paradigm)
- and about Semantic Web paradigm, starting with semantic networks
described as triples by RDF/Owl:SCOM provides a simple and
   straightforward mechanism (addfacet() method)  to build such 'triple
based' semantic networks at runtime (like DOM is the runtime
   data structure counterpart of an XML file)

NOW there is Scala which is both functional and Object BUT not a
purely interpreted metalanguage like Lisp (Lisp allows to define new
Languages with it's bootstrapping/dynamic syntax capabilities)

SO SCOM is not an attempt to do better than breakthrough languages
like Scala, it's only an attempt to show that within Java microcosm,
there's still ways to leverage expressiveness by adopting new
paradigms namely Adaptative Object Model, Semantic Web inspired
runtime data structures (not by extending Java with tons of new
features which address implementation needs without really adding
expressiveness or in the best case clearing out some inconsistencies,
like int vs Integer, [] vs ArrayList etc...)

I still did not get what the purpose of this exercise is.  Why do you do
this?  To what end?

Cheers

        robert

- It(s not that I don't want to use them, in fact I use the Javascript
interpreter in SCOM.
- The purpose is to show to Java programmer's that:
1. there are alternate Object Model paradigms, especially Adaptative
Object Model (where classes are defined and extensible at runtime)
2. That the API may be outside of the class and instead in the
semantic network of agnostic instances (which is the purpose of It
class in SCOM)
SCOM allows easy creation of a semantic networl of its own
instances at runtime, and it is this network which becomes the API,
the It class
API is just an enabler (like machine code vs programming
language)

 

[Robert Klemme]

Yes it's inconsistent:
- because [] and ArrayList/Collections are 2 different ways to handle
vectors/lists (while there is only 1 in Python/Lisp/Perl

The term is not "inconsistency" but "variety": different situations
require different list like structures for efficient handling. You make
it sound like having only one data structure for an abstract concept
would be a value in itself. That might be true in mathematics but not
in a software developer's real life(TM) because even though some
requirements are identical (ordered storage) many others might not (e.g.
varying size vs. fixed size).

- because int is a primitive type (like in procedural languages)
while Integer are Objects (the bypass to put integers in a Collection
in fact)

Oh, Integer can serve other purposes as well: by having an object
reference you can encode more information, namely "value absent" and
"specific int value X". The argument that Java is somehow deficient
because it mixes primitive types with object types is not new. The fact
has some drawbacks (some of which were fixed with autoboxing) but it
also has advantages.

instead all entities in Scala/Smalltalk are Objects (even
functions), and scripting language (Python/Perl/PHP/Lisp) provide lazy
typing and are thus
more consistent (even if at the price of more risk to write
erroneous code which language laziness will let go through)

I don't see an increased risk here. Strong typing prevents misuse. And
the term used for Ruby & Co. is "dynamic typing" not "lazy typing",
while also these languages have strong typing (i.e. every object has a
specific type all the time). It's just that variables and expressions
do not have a type which can be statically determined.

I would not call these languages more consistent. It's just a different
concept and mindset - dynamic vs. static typing.

Kind regards

robert

 

[Robert Klemme]

Please truncate quotes properly.

- The purpose is to show to Java programmer's that:
1. there are alternate Object Model paradigms, especially Adaptative
Object Model (where classes are defined and extensible at runtime)

OK, no surprise here.

2. That the API may be outside of the class and instead in the
semantic network of agnostic instances (which is the purpose of It
class in SCOM)
SCOM allows easy creation of a semantic networl of its own
instances at runtime, and it is this network which becomes the API,
the It class
API is just an enabler (like machine code vs programming
language)

I look at
https://github.com/terimakasi/scom/...04b6293b8544/samples/arithmetic/Test_Add.java

Here you created a graph of objects which contain functionality in a
similar way a interpreter could use internally. Instead of invoking a
method "add" on an instance of a numeric class you have a generic method
"evaluate" - and that obviously behaves different for something that was
created in a special way (with arguments ItAddF.BASENAME,
ItAddF.BASENAME, ItAddF.CLASS_NAME). Basically you replaced specific
methods with specific instances which behave differently. No surprises
here as well - that's a common idiom if you want to stick together
algorithms at runtime.

Now that you've shown it, why should I care? Put differently: what can
I do better with this than with - say - plain Java? Apparently you are
trying to sell something but I fail to see the benefit or why you post
it in a Java newsgroup.

Cheers

robert

 

[markspace]

Yes it's inconsistent:
- because [] and ArrayList/Collections are 2 different ways to handle
vectors/lists (while there is only 1 in Python/Lisp/Perl

Really? In Perl, there's only one way to do something? I admit I'm not
an expert, but in my brief sojourn some 10 years ago I got the exact
opposite impression.

- because int is a primitive type (like in procedural languages)
while Integer are Objects (the bypass to put integers in a Collection
in fact)

So you invented a third way to represent these objects, which in your
view is "more consistent?"

I think you're playing fast and loose with the English language here.
What you're saying is at least non-obvious, and at worst just isn't
true. You might want to back up these statements with some reasoned
arguments if you want anyone to believe them.

instead all entities in Scala/Smalltalk are Objects (even
functions), and scripting language (Python/Perl/PHP/Lisp) provide lazy
typing and are thus

The problem I see with your invention is it's likely to be even worse
than Java's solution. It's likely to be very difficult to optimize for
the JVM. Languages like Python and Lisp which provide "unified
primitives" also provide ways of optimizing them. In my view the way
to get Java programmers to understand these techniques is to discuss
them directly, not bolt a framework on to the language.

And honestly I think these concepts are well understood already. It's
pretty well known around here that C# provides excellent optimization of
its built-in integers (which are objects like Java's Integer) and that
those techniques could be ported to Java, if Oracle ever gets the
resources to do it. But in the meantime the suffering by Java
developers is not too great, so we muddle on.

 

[micha]

Please truncate quotes properly.



OK, no surprise here.


I look athttps://github.com/terimakasi/scom/blob/717f9b9e6748656b5bfcf439147e0...

Here you created a graph of objects which contain functionality in a
similar way a interpreter could use internally.  Instead of invoking a
method "add" on an instance of a numeric class you have a generic method
"evaluate" - and that obviously behaves different for something that was
created in a special way (with arguments ItAddF.BASENAME,
ItAddF.BASENAME, ItAddF.CLASS_NAME).  Basically you replaced specific
methods with specific instances which behave differently.  No surprises
here as well - that's a common idiom if you want to stick together
algorithms at runtime.

Now that you've shown it, why should I care?  Put differently: what can
I do better with this than with - say - plain Java?  Apparently you are
trying to sell something but I fail to see the benefit or why you post
it in a Java newsgroup.

Cheers

        robert

Hello Robert

Thanks for your sharp feedback, you are right the idioms are not new.

In fact what I would like to 'sell' like you say is that 'static
object modelling' is in my view
obsolete because a model (the 'science componenr') is our
understanding of a system
at the time being and it will sooner or later need to be refactored
with all the impacts
to manage (user interface, user's guide, prog's guide, test
suite, ...)

Thus I'm convinced that we need for the future both a new mindset and
a new toolset
which would allow to apprehend the model as a system in a continuum
space
of improvements while from what I've observed until now there is much
more often
the continuous cluttering of a system until it's considered
unmanageable and
then after lots of hesitation ('cost control'), it's garbaged and
rebuild from scratch

My little 'toy project' / exercise is not a solution more an attempt
to motivate
another point of view on common 'oop' paradigms and also a tool
to experiment because of it's constructivist approach (single class).

'Single Class Object Model' seems dummy/stupid/useless but I in fact
found it as
a good creativity exercise with a good 'unfold' potential that's why I
wanted to
share with the community (at least for a feedback, and that's why I'm
getting
so I thank all the people sending me a feedback)

 

[micha]

Yes it's inconsistent:
- because [] and ArrayList/Collections are 2 different ways to handle
vectors/lists (while there is only 1 in Python/Lisp/Perl

To be rather blunt about it -- if you don't know the difference
between an array and a List, to use the Java terminology, and that
they are two different concepts in programming, then you don't have
the understanding to teach people about programming paradigms.

(And anyone who holds up Perl as an example of a consistent language is
clearly insane. Or possibly an alien from Alpha Centauri.)

Leif, first let me thank you for your feedback (would it be blunt or
cute, it's still better than no
feedback at all)

You are right that I seem to 'teach people' what they already know and
moreover much better than me !!
I admit without shame that I'm far from being a Java specialist and I
apologize for my arrogance.

Anyway conceptually an array and a collection are the same
mathematical concept (like
explained gently by Robert Klemme) likewise an int and an Integer are
the same mathematical concept.
Moreover, in Java functions are not 'first class citizens' (like in
functional languages), and the idiom to
bypass this with 'anonymous inner classes' is an idiom which I find
very awkward...

I understand that these are not new argument but the answer of Robert
regarding data structures
for different usages (e.g: performance issues) reminds me the very old
'performance vs expressiveness' debate.

This debate started a long time ago with Fortran vs C, C vs C++ then C+
+ vs Java
and it's also I guess a reason why high expressiveness languages like
Lisp and Smalltalk
are still marginal in the industry (but as weird as it seems in
critical environment like nuclear
plants they are often the best choice).

Another reason is that Java is easier to learn and master than Lisp or
Smalltalk which
in turn raises the reason that universities chose to breed Java
developers rather than
Lisp/Smalltalk developers, all this recursively feeded by the growing
availability of
libraries / frameworks. PHP has also like Java a huge choice of
libraries / framework
but I doubt it would be chosen as a nicely shaped language by language
experts.
In fact all this seems related to the 'learning curve' (PHP is easy to
learn even by
non developers that's why it's so popular I think, same story with
VBA), but the
learning curve is shaped by the universities / industry / authors once
they 'adopt' a language

I found this article (http://azaidi.blogspot.fr/2008/02/reaching-
clojure-on-java.html) which even
if not very new seems still valid in my understanding. It says that
'Java is 21st century Cobol'
and that 'Java is good for enterprisy apps built by large teams of
trained monkeys skilled programmers'
It's pretty 'blunt' like you say and I'm sorry to offend the community
of Java developers who invested
so much of their time to become Java experts.

I guess in the late 80's, C experts did'nt like C++ because they fear
it will force them to drop a lot
of their assets learned on C and to invest time to learn a new
language (with the added drawback
of facing the defaults of a early language and the huge work to
rewrite'standard' libraries like
networking, odbc, high precision calculus, GUI, etc...). The same
happened in the early 90's with C++ vs Java

So Java will sooner or later also be replaced by a new language with
actualized paradigms (Scala seems
a good candidate at the time being). Then why not start to experiment
with new paths (especially
Adaptative Object Model which I'm pretty fond of if it was not clear
until now !!), my toy project is
maybe not the better way to experiment, the intent is only to raise
the motivation to experiment
new paths (at least for me it's a good tool to experiment, that's why
I thought i could be useful
for others too)

 

[micha]

Yes it's inconsistent:
- because [] and ArrayList/Collections are 2 different ways to handle
vectors/lists (while there is only 1 in Python/Lisp/Perl

Really?  In Perl, there's only one way to do something?  I admit I'm not
an expert, but in my brief sojourn some 10 years ago I got the exact
opposite impression.

- because int is a primitive type (like in procedural languages)
while Integer are Objects (the bypass to put integers in a Collection
in fact)

So you invented a third way to represent these objects, which in your
view is "more consistent?"

I think you're playing fast and loose with the English language here.
What you're saying is at least non-obvious, and at worst just isn't
true.  You might want to back up these statements with some reasoned
arguments if you want anyone to believe them.

   instead all entities in Scala/Smalltalk are Objects (even
functions), and scripting language (Python/Perl/PHP/Lisp) provide lazy
typing and are thus

The problem I see with your invention is it's likely to be even worse
than Java's solution.  It's likely to be very difficult to optimize for
the JVM.  Languages like Python and Lisp which provide "unified
primitives" also provide ways of optimizing them.   In my view the way
to get Java programmers to understand these techniques is to discuss
them directly, .not bolt a framework on to the language

And honestly I think these concepts are well understood already.  It's
pretty well known around here that C# provides excellent optimization of
its built-in integers (which are objects like Java's Integer) and that
those techniques could be ported to Java, if Oracle ever gets the
resources to do it.  But in the meantime the suffering by Java
developers is not too great, so we muddle on.

Hello markspace

- regarding Perl, I'm not an expert (not even a seasoned programmer)
but it seems the's only one entity to handle vectors (I'm not speaking
of hashtables here)

So you invented a third way to represent these objects, which in your
view is "more consistent?"

Nope it's not a third way to represent integers, it's away to
voluntarily lower the semantic level at buildtime in favor of a higher
semantic level at runtime. You may think of an application from 2
point of views: it's API and the semantic network of it's instances at
runtime. I feel that putting the focus on the semantic network of
instances (which seems not the common focus as developers are more
focused on the API and the code) would allow to work in a new and more
effective way. Of course this would require wysiwyg tools like
debuggers to visualize these runtime semantic networks. I guess that
this would allow 'on the fly refactoring' and that such an 'object
graph editor' would enhance the way we think and design software
components

I think you're playing fast and loose with the English language here.

Yes my arguments are not so strong and are lacking samples for
illustration and 'proof of concept'. It's an early project (started a
month ago only), and I'm pretty excited by the potential that it
unfolds each day i work on it.. So I'm surely not objective about it.
What I know is that it grasps a bunch of issues that I've seen and
encountered for years ago and I'm almost sure these issues are still a
daily reality

not bolt a framework on to the language

In fact, this project is a reaction against 'deep ultimate class
hierarchies' that I've seen promoted proudly by SW developers/
architects. If we get back from the start a model is at first a
scientific tool which tries to grasp essential properties/behavior of
a real system as a thinking tool to build a better understanding of
it. We know that a model is only a temporary view of our understanding
nd that it will be replaced by an improved model sooner or later.
That's why I dislike these 'deep ultimate class hierarchies' as they
force us to invest time to learn how to use them and once we invested
this time we are then very reticent to get rid of them even if we are
convinced that there is a better alternative

The problem I see with your invention is it's likely to be even worse
than Java's solution.  It's likely to be very difficult to optimize for
the JVM.

I doubt it would be difficult to optimise for the JVM because
precisely the buildtime API is so lightweight !
In fact SCOM is a kind of 'regression': it's a kind a 'machine code
for semantic network of objects'.
I wrote it on top of Java because it's so popular and easy to use BUT
in fact I now think that it could be written on top of the JVM and
that it may become useful not in it's current state (which requires
writing Java code and compiling) but with 'wysiwyg' tools like an
'object graph editor', an approach similar at first glance with UML
modeler but wired in realtime to the runtime environment, so it would
be both an editor, a debugger and an object modeller

 

[Robert Klemme]

Is there a reason why you ignored that request.

In fact what I would like to 'sell' like you say is that 'static
object modelling' is in my view
obsolete because a model (the 'science componenr') is our
understanding of a system
at the time being and it will sooner or later need to be refactored
with all the impacts
to manage (user interface, user's guide, prog's guide, test
suite, ...)

Thus I'm convinced that we need for the future both a new mindset and
a new toolset
which would allow to apprehend the model as a system in a continuum
space
of improvements while from what I've observed until now there is much
more often
the continuous cluttering of a system until it's considered
unmanageable and
then after lots of hesitation ('cost control'), it's garbaged and
rebuild from scratch

It seems to me you haven't done a lot software engineering yet. Problem is: you just shift the syntactic level from plain java methods to construction of object graphs. But that does not reduce the complexity of a system. Both approaches can be made in a good (manageable) and bad (unmanageable) way. You won't stop customers (or reality) from adding requirements to an existing piece of software. Hence with any approach you need to change software which usually comes with an increased complexity. You also need to test an application - black box tests are not affected by your approach at all since all the public APIs remain intact.

My little 'toy project' / exercise is not a solution more an attempt
to motivate
another point of view on common 'oop' paradigms and also a tool
to experiment because of it's constructivist approach (single class).

'Single Class Object Model' seems dummy/stupid/useless but I in fact
found it as
a good creativity exercise with a good 'unfold' potential that's why I
wanted to
share with the community (at least for a feedback, and that's why I'm
getting
so I thank all the people sending me a feedback)

Things would have gone better with the feedback if you had included this information in the first posting instead.

Cheers

robert

 

[markspace]

a reaction against 'deep ultimate class
hierarchies' that I've seen promoted proudly by SW developers/
architects.

See, this is where I think you're handing us a line of bullshit.

NO ONE is promoting anything other than the kind of strongly type
libraries that Java uses. There is no reaction against "deep ultimate"
class libraries. Your project has no reason to exist because your
premise is deeply flawed.

Now if you'd like to show me this reaction by "developers," which has
until now escaped my notice, fine; I'll take a look. But my honest
opinion right now is that you're just some kind of kook.

 

[micha]

See, this is where I think you're handing us a line of bullshit.

NO ONE is promoting anything other than the kind of strongly type
libraries that Java uses.  There is no reaction against "deep ultimate"
class libraries.  Your project has no reason to exist because your
premise is deeply flawed.

Now if you'd like to show me this reaction by "developers," which has
until now escaped my notice, fine;  I'll take a look.  But my honest
opinion right now is that you're just some kind of kook.

you seem not very open neither a nice person, please keep your
opinions for yourself instead of agressing ppl who try to share
ideas

 

[micha]

Is there a reason why you ignored that request.











It seems to me you haven't done a lot software engineering yet.  Problem is: you just shift the syntactic level from plain java methods to construction of object graphs.  But that does not reduce the complexity of a system.  Both approaches can be made in a good (manageable) and bad (unmanageable) way.  You won't stop customers (or reality) from adding requirements to an existing piece of software.  Hence with any approach you need tochange software which usually comes with an increased complexity.  You also need to test an application - black box tests are not affected by your approach at all since all the public APIs remain intact.



Things would have gone better with the feedback if you had included this information in the first posting instead.

Cheers

robert

It seems to me you haven't done a lot software engineering yet.
Problem is: you just shift the syntactic level from plain java methods toconstruction of object graphs

It seems you haven't noticed what's happening with SemanticWeb (RDF/
Owl and triplestores) and how the paradigms it brought could change
the programming landscape
Please don't change your mind, you know better than me for sure...

 

[markspace]

Well, all right, he shouldn't have called ou
a "kook", except that in a technical environment there is a particular
definition. You can disprove kookhood by things like, well, defending
your work instead of attacking your critics.

Yes, he's right; I was rude. It's very frustrating to ask for detailed
information and get glib blandishments that are practically a parody of
themselves.

Still, if he'd rather takes his marbles and go home rather than actually
answer questions, then I suppose that is for the best. I noticed he did
the same to Robert, and he was not rude at all, that I could see. The
OP's probably frustrated as well. Probably best to end what little
conversation there was before it devolves into something worse.

 

[Robert Klemme]

Dang, you did it again: you really need to improve your newsgroup quoting skills. See http://en.wikipedia.org/wiki/Netiquette

It seems you haven't noticed what's happening with SemanticWeb (RDF/
Owl and triplestores) and how the paradigms it brought could change
the programming landscape

I even worked in projects that dealt with aspects of semantic web. Last time I checked it was as live as object databases. Considering the age of the idea wouldn't you believe that it had changed software development _already_ if the benefits are so dramatic?

Basically it's the same niche as AI. To my knowledge there is no common agreement yet what it means to say "a computer (or program) understands something". Basically it is us humans who decide whether we think someone understands something and we do this based on interactions (see turing test). But what aspects belong to this interaction (i.e. only textual via a screen and keyboard, hand shaking, face mimic etc.) is not clear at all.

Over and out

robert