I wrote some text about the meeting. Please review, and I'll add it to
the site.
2005-07-21
Present: Nico, Ernst, Pierre, Michiel
During this meeting we mainly talked about how things work.
datatypes?
-----------------------
The start-point for such a discussion must be the 11 mmbase types we have right
now. Pierre is going to
make those only relevant for the storage layer, because the complete thing is
generalized to a 'data
type', which could also be used more generally. 'getType' of Field would become
a bit odd, because
there appeared a 'getDataType' which would simply imply one of these 11 types.
The original design as mirrored in 'fieldtypedefinition.xml' did not anticipate
more 'data types'
besides the 11 ones supported by mmbase, and which are also visible in the
several specialized
methods in Node (set<type>Value and get<type>Value and in the methods of
'Casting'. Only
'specializations' on those were anticipated, which would not be fully fledges
types in themselves,
because the actual data types are fixed, so those could only deal with
processors and later also
constraint specializations. 'getType' of Field would still make sense, because
that would indicate
the actual (data) type. Michiel was still trying to defend this.
interfaces?
-----------------------
Field/CoreField
----------------
After some exchange of thoughts, we agreed that it may be simpler to drop a few
of the new
interfaces and come to a design like this:
[org.mmbase.bridge.Descriptor] -->
[org.mmbase.bridge.Field] --> org.mmbase.core.CoreField
--> org.mmbase.bridge.implementation BasicField
(btw a descriptor (new in 1.8) does not describe but _is described_, we may
need a better name here,
suggestions?)
So, no 'CoreField' interface, and only one 'field' interface altogether. We are
taking the risque
that the dreaded 'UnssupportedOperationException' should have to be thrown in
certain members of
core or bridge. This stuff seems intrinsic for java (e.g. if you have 'List'
you also are not sure
that every method is indeed useable....).
For example what should Field#getNodeManager do? For 'CoreField' it could
perhaps only throw an
exception now. Perhaps when there is also a core implmentation for NodeManager
it could then be
fixed. What should CoreNodeManager#getCloud() do then? and
CoreNodeManager#getCloud()#getUser()?
Hopefully we will be able to avoid all unsupported operations if e.g. we define
the 'coreuser' object
or so. This is though outside the scope of this project which only is about
field types (or more
generally 'data types' now).
Btw, we'll end up with dependencies like this:
org.mmbase.bridge.implementation implements org.mmbase.bridge wraps
org.mmbase.core
org.mmbase.core implements org.mmbase.bridge
which could still be interpreted as 'circular' perhaps, because the package
structure suggests that
'brige.implementation' is a part of 'bridge', while it uses 'core',
which in turn implemets bridge.. I think that actually it would perhaps
have been better to place the implementations next to the interfaces
rather then 'under' their package.
DataTypes
---------
'datatypes' would probably receive there own top-level package like
'org.mmbase.datatypes', and
there is no need for interfaces here. These things are straight-forward
containers, for which
alternative implementaitons are are not anticipated or necessary. Of course
this does not take away
that they could be extended and plugable.
Michiel
--
Michiel Meeuwissen mihxil'
Peperbus 111 MediaPark H'sum [] ()
+31 (0)35 6772979 nl_NL eo_XX en_US
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
