Since scala is statically-typed, the ide can (and does) give you contextual
help very easily
On Jan 8, 2011 2:21 AM, Martin Makundi martin.maku...@koodaripalvelut.com
wrote:
But it will do the right thing about 90% of the time. you'll
subconsciously
work around 4 or 5% of the rest that doesn't
Analysis is the a background process that parses the file and highlights
errors, warnings, etc while you type. Eclipse has the same, though the name
may be different. It's slow in Scala, like compilation is.
Yes, it gives you context help. It's very helpful with a caveat: in
Scala, there
Analysis is the a background process that parses the file and highlights
errors, warnings, etc while you type. Eclipse has the same, though the name
may be different. It's slow in Scala, like compilation is.
If it is slow then it is pain. Computer speeds might enhance faster than ides ;)
On Sat, Jan 8, 2011 at 1:25 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
What I hate about java is its one-dimensionality... ehh.. say you have:
object man
object man carrying bag
bag carrying pencil case.
This isn't a Java problem. This is a design problem.
How would you
Hi!
You would use a more domain-oriented design approach. Setters/getters
are merely used because of all the frameworks that support (and
expect) them. Why do you care where the man is carrying his pencil?
Perhaps he's keeping it in his sock. All you want to do is ask the man
object for a
On Sat, Jan 8, 2011 at 2:59 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
It should be possible to say that man will proxy by default all get
methods of his belongings, It should be possible to say that bag
will proxy by default all get methods of his belongings. Same with
Hi!
public T T borrowObject(ClassT objectType)
where you can do
Pencil p = man.borrowObject(Pencil.class);
Either way, you have to put logic somewhere that tries to figure out
what the heck you want to borrow and then figure out where the heck to
get it.
If it is done at compile time
On Sat, Jan 8, 2011 at 4:19 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Either way, you have to put logic somewhere that tries to figure out
what the heck you want to borrow and then figure out where the heck to
get it.
If it is done at compile time you don't need messaging
Hi,
currently every component that requires the markup to be in an
associated file must be derived from Panel. Every component that want
it's markup inline must be derived from Fragment. I've changed that
and moved the respective source code into something I called markup
sourcing strategy. I'm
sounds interesting, but your patch didnt make it. attach to a jira issue?
-igor
On Sat, Jan 8, 2011 at 2:54 PM, Juergen Donnerstag
juergen.donners...@gmail.com wrote:
Hi,
currently every component that requires the markup to be in an
associated file must be derived from Panel. Every
Ok, you need to debug whats in a Model when it is added to
a Component. So, in setModelImpl which is called by the
Component constructor you add code to get the object
out of the Model (if its not null, of course) by calling
model.getObject():
void setModelImpl(IModel? model)
{
if (model
On Sat, Jan 8, 2011 at 7:03 PM, richard emberson richard.ember...@gmail.com
wrote:
Ok, you need to debug whats in a Model when it is added to
a Component. So, in setModelImpl which is called by the
Component constructor you add code to get the object
out of the Model (if its not null, of
On 01/08/2011 05:16 PM, Jeremy Thomerson wrote:
Not all that amazing. This is happening*during construction* which always
leaves objects in fragile states. It's assumed that you can't start
monkeying around with an object's state until construction is completed (and
not expect side
13 matches
Mail list logo
