Niclas Hedhman wrote:
On Thursday 04 March 2004 01:10, Berin Loritsch wrote:
The current state of merlin is
that there are so many contracts that I feel like I need to understand that
I can't possibly keep them straight.
If this is the case, then we are failing in the education sector.
Perhaps, Stephen (and I to some extent) are too quick to refer to the advanced
sections, instead of promoting the "simple side". Perhaps there are more we
can do in the "kitchen sink" area, for simpler usage patterns, which I think
we all can agree upon are desireable.
That will help, but bear in mind that if I want to do something or extend Merlin
in some way that is not how the current authors feel it should be extended, then
I either need to reimplement everything from Merlin that I need with a new
container I can control, or I need to resort to ugly hacks. So there are two
levels of education that need to be addressed.
I don't get the
feeling of simplicity, or "it just works" when I look at either Maven or
Fortress (and I wrote the latter). That is the main goal I want to
encourage you to focus on.
static public void main(String[]) "just works" and are suitable sometimes, but
without "enforcing" framework standards, you will always end up with a mess
on the component re-use side.
Yes, but what exactly needs to be enforced? I get the feeling that too much
is enforced for little known gain--at least to me. That is where the education
comes into play. But then again, I want something so transparent that I
shouldn't need education. Perhaps it is a holy grail that can never truly be
attained, but we can make strides torward it.
What about mixing and matching components from different lifecycle contracts?
It is possible provided your container can support it. I mean, do I really need
to hand write a wrapper for a component that was designed for PicoContainer?
If I have to resort to hand coding wrappers to use components designed for
other frameworks, then it isn't very useful and it is more pain than pleasure
to work with. I.e. it doesn't "just work".
I strongly support the "Software IC" concept, and I think it could really
work, but the software engineering community can't or don't want to make it
happen. As many technologies as I have investigated and used over the years,
only Avalon is even close to really trying.
And when we manage to get to the point where a Publishing Service exists with
an associated TCK, slowly components will show up, with high quality,
conformant, easy to use, et cetera, which will lead to a network effect, and
hopefully an avalanche of converts, since "Avalon Users finish projects in a
fraction of time..." starts to become apparent.
The similar patterns have happened several times in the Electronics industry
(the transistor, the IC, surface mount devices and FPGAs), but what has been
very significant the last 5-10 years is that the TOOLS supporting the
components have improved tremendously, since the tools has very precise
standards to work with. A modern design tool can NOT be effectively used to
construct a tube amplifier, but easily put together a 32bit miniature
computer.
+-------------+ +------------+ +-------+ +------------+
| Strict Spec | --> | Components | --> | Tools | --> | Effeciency | --+
+-------------+ +------------+ +-------+ +------------+ |
^ |
| |
+-------------------------------------------+
My ambition is to bring Avalon into the "loop" in the above picture.
That is a good ambition, and it can be acheived when you have the right
contracts. I think the misunderstanding here is that I perceive that the road
Avalon taking is that it is enforcing the wrong contracts, or too many
contracts. We can really simplify things if we wanted to, both from an
implementation perspective and from a definition perspective.
I don't mind a strict spec as long as that strict spec isn't 100 pages long.
If you can fully specify the strict spec in six or seven pages (hopefully less),
then we have something that would work for most developers. Tools are great,
but if all they do is hide the underlying complexity you are going to come into
some nasty surprizes if that complex set of contracts changes.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
