Re: Fragility/Stability of Wicket core
Richard, This is how wrapped models work by design. They need to know the component they are assigned to to be able to find the resource bundle. And the owning component needs to know its parent to be able to look in all resource locators (component, package, application, ...). It is the same with components which want to work with their markup - they need to be either component-with-associated-markup, like Page or Panel, or they need to know their parent-with-associated-markup to be able to find the piece in markup which is for this component. It may look to you that it is wrong/inconsistent/... but actually this is by design. I hope it is clearer now. On Sun, Jan 9, 2011 at 3:01 AM, richard emberson richard.ember...@gmail.com wrote: 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 effects). From the ResourceModelTest.java IModel model = new ResourceModel(test.label); Model is constructed. Can you call model.getObject() yet? No. Label l = new Label(testlabel, model); Component containing Model is constructed. Can you call model.getObject() yet? No. add(l); Parent Component containing Component which contains the Model is constructed. Can you call model.getObject() yet? Finally, Yes. If the advice to a user is to not print any debugging information about any state until the application is completely constructed, then, that, in generally, really would be amazing. I think ResourceModel is a special case that depends upon being is a fully constructed Component tree. Just as a Model which communicates with a DB can not be interrogated until its connected to the DB. As an addition, if such pieces that require some level of supporting infrastructure prior to interrogation had comments warning the user that they needed special care, most users would not remember such admonishments while adding general debugging statements (especially, if the object in question (a Model) was one of a number of such types of objects (Models) where most of the types are safe under examination.) Richard -- Quis custodiet ipsos custodes
Re: Scala-Wicket Help and Advice
I am sorry, but I can not disagree with you more about Kuhn's The Structure of Scientific Revolutions. Its about resistance to change and not scientific truth and, as such, it has generally applicable. At its crudest, its about the old, vested guard being unwilling and/or unable to move with the changes; the intransigent, causing great damage and delay, either get slowly pushed aside or die off. Its lessons are applicable to a broad spectrum of endeavors, not just the Sciences. I recall when Kuhn's book came out, the resistance to his ideas in the scientific community, rather self-referentially, was a demonstration of his thesis. In addition, it has nothing to do with *the truth*. Science is not about *the truth*. Its about what works; how well it explains the current observations and the accuracy of its predictions. If you want to listen to people talk about *the truth*, find an alter. Rather, Kuhn addressed the bumpy road that leads to scientific advancement disputing the idealization of an orderly, reasoned progression. He discusses the political, sociological and cultural resistance to change in the context of the advancement of science. To resolve this point, simply show me where on the Kuhn's book Wikipedia page it mentions *the truth*; its about resistance to change. So, one can ignore this insight into human behavior, both the individual human and humans in organizations, and risk becoming the problem rather than the solution, or one can embrace it, go Meta and surf the shock wave. Its not so much a matter of one's chronological age but rather of one's the ability to remain young. Would you rather sell flavored water or change the world? Resistance to change is the key. When C++ came out the entrenched in the C community resisted. When Java came out the entrenched in the C++ community resisted. Now, with Scala the entrenched in the Java community resist. Fine. History may not repeat itself, but people do. Lastly, I still maintain that project coding standards are the key. I have throughout stated that without appropriate standards, there are features of Scala that, with the current crop of programmers, could lead to hard to understand and maintain systems. But that such a caveat to Scala's use is no more or no less important than requiring standards for Java or (especially) C++ projects; nothing new here. When Scala is taught broadly in colleges, the strictures of such standards can be relaxed. Currently, its a self re-enforcing chain: Not enough Scala programmer, Risky to have a Scala project, Too few Scala projects, Too few Scala jobs, Few programmers willing to learning Scala. My small contribution is to manifest a Java-like Scala web framework easing, in a small way, Scala's adoption. Richard On 01/07/2011 09:30 AM, Jonathan Locke wrote: Kuhn's The Structure of Scientific Revolutions has to do with people denying *the truth* when there are radical paradigm shifts in knowledge. I hardly think Scala qualifies for this analogy. Most of what Scala does has already been done in one form or another. What it represents is the application of long-existing knowledge from universities to *industrial* problems. As did Java. I do not deny that Scala is better than Java in terms of its abstract approach to a variety of problems that Java doesn't and probably never will solve well (and these are problems that I am excited to see solved). What I am saying, however, is that your idea that it's going to get widespread adoption is very naive regarding the contexts where it would need to be applied. I think Scala is going to become difficult to follow in the absence of these magical coding guidelines (which are always bent or ignored) much more quickly than Java does, which means it is going to prove exceptionally hard to manage on a large team. Which is going to make it difficult for managers to chose Scala (they don't want to make their own job harder or riskier). They have to understand and be comfortable with all these deep and dangerous features and techniques. Which really means that they have to be fairly top-flight coders. I don't know about you, but relatively few of my bosses have been this intellectually adventurous or willing to take on risk (and for good reason: they are there (unfortunately perhaps) to produce business results, not technical excellence). I think Scala's forte is going to be allowing very small teams where everyone understands all aspects of Scala fairly deeply (i.e., you'd better understand monads and Scala's type system fully because SOMEONE on your team will use a feature or technique if it exists!) to produce amazing results *very* quickly. That is something of a revolution in itself, but I think it will be a cottage industry relative to the size rest of the software industry. This is not necessarily a bad thing. If you want to work with smart people, Scala is going to be a pretty quick way of identifying smart people! I know this from
Re: Scala-Wicket Help and Advice
Actually, in Scala it's idiomatic to skip the type on vals (unless they're complex structures or you NEED to declare the type as a higher-level, like it's a public val of a java collection and you want to enforce the interface). Also, if you type new Modelblah() and do an insert-variable while it's under the cursor, it will create the val declaration for you (with the type if you want). On Sun, Jan 9, 2011 at 8:11 PM, Liam Clarke-Hutchinson l...@steelsky.co.nzwrote: Biggest thing I miss in IntelliJ when coding Scala (I write Wicket in Java for my dayjob) is my autocompletion of types. In Java you can type in IModelString foo = new and hit Ctrl + shift + space and it'll provide a list of all types that subclass IModel, but for the time being (IntelliJ 10, build 99.32, Scala plugin 0.4.407) val foo: IModel[String] = new with ctrl + shift + space does nothing. But IntelliJ does a really good job of navigating some of the byzantine Scala code I've been dealing with. (Some people seem to think that every Scala library should be a DSL replete with mysterious operators and where everything happens via implicit conversions nested three types deep. :) It's definitely the best I've seen for Scala, but it's not quite at the Java levels of polish - but then, JetBrains have been working on the Java side of Intellij for 10 versions now. ;) On Sat, Jan 8, 2011 at 10:34 PM, James Carman ja...@carmanconsulting.com wrote: 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 work, and the remaining 5-6% will irritate you. I am used to coding 90% using context help with eclipse (ctrl+space). I am a fast writer but that speeds up my coding by 1000%. Will an IDE do that for scala 90%? I consider context help and quickfix proposals most important for speedy work. - imports sometimes get messed up (relative vs absolute, I hate that in scala) and require a manual correction Import organization is important to me also. I like to spend my time coding logic instead of organizing text files. - analysis is useful about 90% of the time, but it's so slow you may just not care for it What is analysis? I hope it isn't the context help ;) ** Martin - it crashes the JVM on Oracle's JRockit (although IDEA is much faster in that jvm) On Fri, Jan 7, 2011 at 5:37 PM, Liam Clarke-Hutchinson l...@steelsky.co.nzwrote: Define complete. On Sat, Jan 8, 2011 at 7:52 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Nice or complete? ** Martin 2011/1/7 Jonathan Locke jonathan.lo...@gmail.com: Have you checked out IDEA? My Scala friends tell me it has pretty nice Scala support. Jon Less is more. http://www.amazon.com/Coding-Software-Process-Jonathan-Locke/dp/0615404820/ -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Scala-Wicket-Help-and-Advice-tp3174601p3185239.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: Scala-Wicket Help and Advice
I understand what you are saying, but I also think you are playing semantic games here. By truth, I was referring simply to objectively testable results (the scientific method), not opening up a philosophical discussion on the nature of truth. But in any case, there are certainly no objectively testable results possible in terms of what language is best. I think we can agree on that. Therefore this argument from Kuhn doesn't really apply very directly. In fact, I'd go so far as to say that the whole discipline of computer software engineering is a gray area, with some of it (actually very little) being scientific and the majority of it being a difficult-to-teach art. So at best, I think all Kuhn is saying that's relevant to this discussion is that people are slow to change. He's hardly the first to note that. What's more, in non-scientific areas like programming they may actually have more reasons than entrenchment to avoid a particular change (which can't be objectively proved no matter what the method). Certainly this is true for me, as I am aware of the benefits of Scala and actually WANT a replacement for Java, but I still don't want to choose Scala for the reasons I outlined and not simply because I don't want to change my way of doing things. If I was that type of person, would I have created Wicket? Something that people told me for years would never be useful because it bucked the common wisdom that you can't have server side state? Could it be that there are some reasons besides entrenchment that people are not flooding to Scala? But regardless of what we both think about Kuhn, your argument is funny to me because it's an attempt to apply logical reasoning to what purely artistic choice. Would Kuhn say that his book applies to the choices of materials by visual artists? I tend to think not, because there would be no way to test his theory. And anyway, if you're going to go in this direction, why isn't it also clear that Eiffel, Haskell and Clojure are The Way forward, as you are suggesting Scala must be? After all, if this is a discussion about science and politics, surely this is objective as well? Don't you think the choice of languages in software engineering depends not so much on would-be-objective assessment of technical excellence, but rather on subjective experience, artistic temperament and perceived applicability to the problem at hand? For myself, I love a lot of Scala's features and said as much when I first ran into it, but after some reflection it simply does not fit my minimalist artistic aesthetic and it has a lot of dangerous moving parts that I don't want in the hands of co-workers. You can think what you like, but this reasoning has nothing to do with any entrenched political interests I might have. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Scala-Wicket-Help-and-Advice-tp3174601p3207861.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: [Announce] Migration of wicketstuff from sourceforge to github is now complete
On Sat, Jan 1, 2011 at 2:01 AM, Michael O'Cleirigh michael.ocleir...@rivulet.ca wrote: I am pleased to announce that the migration of the wicketstuff project from sourceforge to github is now complete. I've added wicket-auto...@lists.sourceforge.net to the email plugin for github.com/wicketstuff/core, so with any luck we'll see commit messages arrive at that list. Martijn
