Weak AI to Step against Context Free Grammars?

This article stems from a practical problem. If you’re worried I’ll be barking up my own tree, you are right. Otherwise, read on and bark along.

My new code editor is now available for trying out. ee-ide doesn’t boast much for now, but the underlying application platform, Kippu (?Kiphu) – based on a trial F* implementation, is more than promising, and I feel encouraged given a mere 52 hours logged into my project manager.

When quoting that I write development tools, I often meet a do we need another IDE shrug kinda thing. People just quote Eclipse and Netbeans, or backtrack to IntelliJ.

I beg to differ. Have a look at Antegram for web or Antegram for java and you’ll get a feel of how alluringly different an IDE can be.

Now to the point. ee-ide is a kind of prequel to Antegram. Since I dropped XML annotated code for now (just for now), I may have to give in a little to the establishment:

• Syntax highlighting
• Code validation
• Hinted typing (e.g: displaying a drop down menu showing all functions available from a given variable)

I can’t really dedicate time to each and every language out there, and a soon to be, fast and ready extension framework won’t allow me to just sit and wait (for somebody else to integrate parsing functionality on a case basis). Instead, I’ll be looking for simple analysis techniques to help me providing fairly reliable services. For example:

• Discovering language tokens – An example of that is when a token appears in all, or nearly all, files of a given type.
• Semantic closure – a name occuring only once in a file is a sign that something’s going on. It could be that the name hasn’t been spelled correctly, or it could be that the name is defined elsewhere (for example, in a file referred by name in the current source file)
• Terminals – given correct productions in a given language, we can surely evaluate with fair confidence what does (and doesn’t) count as a valid line terminal.
• Brackets – even if we don’t know what bracketting style is used outfront, we can use valid code to detect ‘immutable pairs’ that constitute brackets in a given language.
• Foreign forms – just today, a colleague pointed out my giving into old habits by declaring variables using C++/Java syntax. Unfortunately I meant writing AS3 code. This kind of error shouldn’t be too hard to spot, even without language specific knowledge.

I’ll definitely have some fun trying to write reliable solutions using generic strategies, and I hope the result will match my expectations.

Finally comes the question: why should somebody use ‘rough and ready’ technology while the competition uses strict parsers that get it right every time? Three answers to that:

1. Rules versus Practice – where a strict parser lets you write any code, a soft parser willl potentially endorse good practices – what might be perfectly OK according to a parser may amount to poorly formatted, awkward code, and the soft parser will let you know.
2. Graceful performance degradation – even if your code is a weird avatar of an existing language that doesn’t really compile until it gets processed in some way, or code written in a really obscure language, a soft parser is more likely to discover (and respect) patterns idiosyncratic to your source files without giving up on validation altogether.
3. It’s a N-body problem - never mind the fact that F*(and some other stuff coming really soon) will make extending ee-ide and other Kippu apps a gentle breeze, I’ll be iterating the proof that 10 years off the beaten track likely got me to be a happier and more productive developer than average. This time I’ll have pretty standard features to lure you in and the quixotic, yet commonsense stuff that’s motivated the Antegram iterations in the first place plus other stuff that mainstream IDEs don’t really bother bringing up, given that dominating the market isn’t the biggest incentive for innovation.

If you’re not deeply shocked by my lack of excitement and interest for regular parsers

…wish me good luck.

Blender >> Panda3D: Clearing the Cache

Part III of this Panda3D/Python crash tutorial. I hacked some code into Tut-Step-2-Basic-Setup.py (from the Panda3D tutorial).

In Panda3D, you can load geometry using loader.loadModel(PATH). Obviously just loading sample models doesn’t feel like overwhelming freedom. Here’s some tips for loading from Blender:

• Just download Blender and export to X. Blender exports *.x out of the box and loader.loadModel recognizes X directly (formats, conversions and the afterlife of 3D models in Panda3D are somehow described elsewhere).
• The (double) conversion preserves (at least some of) the material/colour information. That’s cool. Also, the models load to scale (if it’s 1.0 units in Blender it’s 1.0 units in Panda3D).
• By default, Panda3D provides ambient lighting. This means we don’t need to add a light source to see ‘something’. Sure, it ain’t pretty.
• I loaded my files relative to the current directory. You can select a model-path similar to a classpath.

Panda3D caveats

• Select [Swap  ZY] in Blender export settings (or fix it your way). Otherwise your model’s top will turn it’s back to you.
• By default, Panda3D caches loaded models in the [modelcache] directory. If you export your model, change it in blender and export again, cached geometry will be loaded instead. I don’t know how to disable this but you can at least delete all files in the cache (all files. It’s OK.)
• You need to provide a file extension. Python seems to be assuming .egg.pz otherwise.

Python caveat: the Python interpreter doesn’t like mixing tabbed and spaced indents. By default the tutorial code I’ve got seems to be using 2 spaces per indent. Because I use hard tabs 2 spaces wide, it took me a while to work out why my code (tabbed) conflicted with the tutorial code (spaced). Remember python doesn’t use decorated brackets, so it’s gotta be strict about indents to figure nesting levels.

I paraphrased that code, as below:

box=loader.loadModel("models/pawn.x")
box.reparentTo(render)
box.setScale(1,1,1)
box.setPos(0,0,0)

Apart from the quirky reparentTo function, it’s all great, simple functions so far. Fingers crossed.

Sorry. I love Blender. I can’t help you if you don’t love Blender.

Global Scope – Panda3D’s Natural Habitat

You may not be without knowing that dumping variables and functions into global scope is mmphf… Bad Practice. Except maybe when writing an API flirting with a domain language’s ambitions.

Second installment of this Panda3D/Python crash tutorial. Note that Panda3D has a great tutorial – so does Python, I guess. I’m kind of skipping through the tutorials and shedding light on obscure areas. Also, my rice didn’t burn and even tastes pretty good (see below).

base, render, camera, run(), … all these global functions and variables litter Panda3D sample code. How many bamboo trees in this jungle? Where does this stuff come from?

Well. A lot of this stuff comes from /direct/showbase/ShowBase.py in our Panda3D install folder. They are defined using something like:

__builtin__.run = self.run

Python uses  __builtin__ as a magic module. In other words everything that’s in there is ‘global scope’.

I wrote a little script that will show you what’s in Python’s global scope by default, and what Panda3D adds to global scope, including the ominous wantUberdog entity. It’s my first time writing Python code. I could put this together without going back to school, so I  hope it will be self explanatory:

# ________________________________________________________
# First, let's check builtin entities in python
#
import __builtin__
print "Before importing DirectStart: --------------------"
print "here's the list of objects in static import ------\n"
stdstatic=dir(__builtin__)
stdstatic.sort()
for k in stdstatic:print k
# ________________________________________________________
# Now let's apply the default Panda3D import
#
import direct.directbase.DirectStart
# ________________________________________________________
# Next, evaluate builtin functions in Panda3D
#
print "After importing DirectStart: ----------------------"
print "here's now the list of entities added by Panda3D --\n"
p3dstatic=dir(__builtin__)
for k in stdstatic:p3dstatic.remove(k)
p3dstatic.sort()
for k in p3dstatic:print k
# ________________________________________________________

dir(__builtin__) returns the names of all built-in entities as a list/array (there’s not a very big difference here). Note that I refer to these entities as ‘static’ in the code. I feel, however, that it’s a gross approximation.

I hope somebody’s enjoying this. Safari4 was such a pain on my netbook  -hanging without even using any processing time or memory – that I had to uninstall it. I also uninstalled Firefox from my winxp partition (poor support for scrolling gesture) and I’m actually using IE today

On a more {pleasant} note, I just noticed how unfriendly WordPress can get when trying to include sample code. And my rice probably burned by now.

Back to Python, I tried to run this stuff from IDLE on my standard Python install. Sure I can get Panda3D into sys.path. However that won’t actually help dlls getting onboard. Ideas welcome.

Image: Geeky Gadgets (happens to be a USB drive. Geeky Gift  for a Gal?)

Python ‘Classpath’ – A Snake Digging the Panda’s Egg

I’ve just installed Python and Panda3D, then realised that… …Panda3D installs it’s own (outdated) Python release.

This may be the first of a small series of Python/Panda3D tutorials. As it turns it will be a ‘peer to peer’ tutorial, since I’m learning both Python and Panda3D as I go.

I won’t assume that you can’t write a computer program or don’t understand 3D. So I’m afraid this won’t be suitable for complete newbies. More like a crash course.

OK, after running a couple of examples, my first question was:

How does Python find imported modules?

Yes, there is a ‘classpath’:

1. Current directory, ie, the target directory when starting our python app.
2. PYTHONPATH environment variable
3. .pth files; .pth files are used to add locations to the search path – if a pth files is on the search path (in an already known location), then it is read and all files listed there are also added to the path.
   This is convenient – say we have a foo/script.py script, then all we need to import custom modules is define a foo/import.pth file pointing at our custom module definition files.
4. sys.path variable. At runtime, we can reach (and edit) this by importing sys, and print the current classpath using print sys.path.
   Changing sys.path at runtime allows dynamically adding locations to the classpath.

Most of this is  documented. The best of it,  .pth files, is apparently still undocumented.

I’m just running the sample programs so far. My guess is that Panda3D is adding its eggs to PYTHONPATH.

Import statements

Python uses both import X and import X from Y statements. The equivalent of the java import is import X from Y (I found a nice article detailing python imports)

Why bother?

Sure, if you install P3D the way I did, you don’t really need to know about sys.path to get started with the sample programs. But then, until we know how the path works, we can’t release software. Let’s be agile. We don’t want to wait another year until we release our first P3D app.

Give me a Beautiful Cloud

I’m looking at the tag cloud on this blog and I think:

This cloud looks like a mash.
I could make it look better by removing the ‘Programming’ tag from my posts. But then I have many posts. I don’t know that there is a one step method to remove a tag from all my posts.

Then I think. What if we used a little 3D algorithm to illuminate the tag cloud?

To be continued?

F*: Let’s Swing the Undo Functionality

I have implemented the undo functionality for XML support in ee-xml and I am doing the same for the text editor.

Undo is a little bit interesting in application development, and it’s a good case study for F* development: in F*, we try to keep ‘features’ separate and self-contained.

An undo manager needs to coordinate actions triggered by several, separate features – by ‘features’, I mean ‘value increments’ and by ‘separate’, I mean, bundled in separate package, and written in such a way that deleting a feature package will remove a feature completely without otherwise threatening the integrity of an application.

Generic Undo Functionality

When I wrote the {undo} feature for XML, I see in retrospect that I planned on sharing code. This uses the following classes.

• UndoSetup. This is a feature setup class and is typical of F*. In this case, UndoSetup adds a couple of menu items in each new application frame (as an AppFrameCreated.Listener), and registers a listener on a Keyboard class.
• History. This manages a list of undo actions and provides the undo/redo actions. More interestingly, this implements ModelAction.Listener, which allows it accumulate UndoableAction items
• Undo, Redo and HistoryKeyHandler. These are just UI event handlers allowing the user to invoke History methods.

• All classes are bundled in the same package (except Keyboard, which belongs to an amorphous utilities package). notification interfaces are all bundled in an event package as notifications are normally made available to all actors in the system.

Undoing XML actions

All XML edits are created as UndoableAction instances, then applied, then a notification is generated via ModelAction. I packaged XML actions separately, which may be OK (several features may need to use the same actions). Where I’m less convinced is that these actions are really provided only so that they can be undoed, and the packaging doesn’t really reflect that. Here, following feature and value driven separation, I have two problems:

1. The {undo} feature is generic. It doesn’t do anything and is meant to be shared by actual features (ie, undoing XML actions, text actions, image edits… ). Eventually I’ll want to resolve this. generic {undo} is a framework feature targetting developers, not an application feature targetting end users.
2. The undo functionality for XML (the actual value increment) is not represented anywhere. XML-actions was designed as a utilities package. As such it is ill formed, because it generates application level notifications. In the meantime, it is really the basic xml edit feature, {xml-edit}, that supports the undo functionality by relying on XML actions and notifying ModelAction.

Undoing text actions

My first reflex was to hook a (swing) DocumentListener onto my text components to generate UndoableAction instances from DocumentEvent. However, the structure of document events in swing is somehow intimidating. I didn’t intend to spend so much time on this, and I spotted nearly simultaneously that I could register an UndoableEditListener.

Behind UndoableEditListener, there is a structure very similar to what I originally designed – but provided at API level, and slightly more complex. From UndoableEditListener, we get swing UndoableEdits intended to be operated upon by an UndoManager. As I already have my own undo manager (the History class) I wrap the UndoableEdits using an adapter class. I then notify my edits using the ModelAction dispatcher.

This works (almost) like a charm, especially considering that (unlike with XML, where I actually had to painstakingly define each action and it’s undoing) we don’t need to distinguish between edit types. Leaving a couple of open questions…

• Using an adapter worked fine to the extent that swing’s UndoableEdit and my UndoableAction share core functionality. However, the swing interface provides a die() method used to release resources (if any). In order to ensure that die() is invoked, I had to provide a secondary interface and do some typecasting from History. Obviously I had no intention to grow my existing UndoableAction interface. But then I still find myself with an additional interface (in this case, just a resource release interface, Heavy). Frustrating…
• When undoing text actions, we don’t generally expect or want to undo input character by character. UndoableEdit distinguishes between significant and non significant edits (and I’d rather if special symbol inputs/deletions counted as significant versus alphanumerical input) but… …whatever implementation is underlying the edits fired by swing’s PlainDocument is a quick affair that doesn’t distinguish between significant and non significant edits. Pity considering I actually spent the time to fit an edit accumulator in my implementation, based on the significant/non significant distinction…

Conclusion

Writing this article and implementing the undo functionality for text took 110 minutes.

Overall, I somehow prefer the implementation of undo for text. Unlike what I did for XML, the feature is completely self contained and advertises itself as such.

It may seem that not having undo for XML actions defined as an actual feature makes no difference. I think it makes a huge difference: I could get rid of undo for text by deleting the package and crossing one line in the features registry. In contrast, removing undo functionality for XML would require updating several classes within the {xml-edit} feature.

More importantly, undo functionality for text is easier to upgrade than it’s XML counterpart.

Source?

Well… you might as well ask, or maybe I’ll link bits and pieces later on (mind, the java tutorial does have an article about this).

Text Editors – Can we still do Better? Oh My…

What a strange idea you say, do we need yet another text editor?

Well… maybe…

I’m adding a text editor to ee-xml and I’d rather say it’s not for the sake of it – the application framework behind ee-xml (or lack thereof, given ee-xml is based on an F* derivative) is doing jolly good and I’m quickly heading towards an IDE that will bridge the gap between Antegram (XML-annotated code editing) and standard IDEs (text-oriented).

I won’t claim that the following features aren’t in any other text editor, but I haven’t seen them before (with the exception of templating which is ‘kind of’ available in Eclipse and other IDEs), and I feel that they will make the difference in many situations:

• Creating many, many new files in less time. Creating a new file is rarely a one step process. Most editors I’ve seen pop a file selector for that, and file selectors don’t provide fast interaction. Say you want to create a batch of 20 to a 100 files or more in a really short time, what would you do? I decided to reuse a feature from Antegram: given a selected folder in my file browser, I have a tiny text field at the bottom of the browser and I can just type in the names of all the files I need created. This allows me to create class members quickly in Antegram and I doubt many text editors can get as fast as that.
  >> As I’m currently extracting class skeletons from a spec, this is exactly what I need to do (and there’s more to it, see below…)
• Renaming and moving files quickly. Renaming a file can also turn out a bit slow in many situations, the fastest ways I know still being, do it from the desktop, or use a command line. When refactoring classes, renaming is common. So instead of having a label at the top of my document views, I’ll replace it with a text field. As a geeky way to move things around, I might even include the full path.
• Templating new files. Still on my ‘file generation spree’, I surely would like to template the creation of my text files – what’s the point in just generating blank files? After considering, I’ll probably add templating rules rather than an explicit drop-down menu. Files can be templated by extension and by name – this gives a first benefit to clear naming conventions.

There’s a few other small things that will make the difference – the non-overlapping document views that I’m so fond of, a speedy ‘open file’ featurette by-passing the file selector (backed by an implicit, localised search) and… well… some surprises.

Is it worth it? Yes, yes and… yes! I’m not even bored – after all, thinking innovation on such a tiny scale is a challenge in ergonomics design.

By the way, we’re still open to suggestions, 24/7.

Understanding PureMVC

I’m writing a bit of code using PureMVC, so I thought I would share this experience – gone all my merry way doing just that.

In this article, I’m covering basic separation principles. Then I’m introducing MVC. I describe PureMVC, explain what it’s about in fairly abstract terms, and try to help you figure out whether it’s worth your while.

If you’ve never seen PureMVC code, I’m afraid you’ll have to look elsewhere (especially if you’re into ‘code makes more sense than theory’).

First things first

MVC is a meta-pattern mainly used in developing applications and application components. MVC separates applications into three tiers: Model, View and Controller. The model is your data, the view represents your widgets or components, and the controller determines  how the model and view affect each other.

Separation

Like with many architectural patterns, separation is essential to MVC. There are many ways into which you might either need or wish to ‘separate’ application tiers:

• Logistic separation: concurrent tiers may be deployed on different computers.
• Physical separation: concurrent tiers may be separately bundled – you store the source code for each tier in different folders.
• Logical separation: concurrent tiers can be compiled independantly from each other.
• Runtime separation: at runtime, concurrent tiers reside and hold resources in separate areas of memory, and may run asynchronously
• Socio-Professional separation: different people (or different companies) each write a part of the same application
• Conceptual separation: concurrent tiers use concepts from different domains
• Cybernetic separation: there is less communication across tiers than there is within any given application tier.

Depending on where you stand, you may have no choice – for example you may need to keep a database on a server and present information in a web browser – or you may simply wish to keep things separate in some way or other for the sake of clarity.

In the meantime, we’ve already agreed that MVC is mainly for writing applications. This surely implies that application tiers, however separate, need to communicate. It is useful to remember that, although you can achieve absolute separation in some respects (e.g., Physical) you can never (nor should you want to) achieve complete cybernetic or conceptual separation – all components within an application contribute towards the same purpose (business logic) and in order to do so, they will communicate – except to the extent that digital communications are replaced by human communication.

Maybe another, essential consideration is that separation is flexibility at a cost. Such cost will generally include additional design efforts as well as areduction in quality and/or efficiency. Also, you will incur this cost while you are writing and maintaining your application, not just while deciding how components should be separated.

MVC as a Meta-Pattern

MVC is a high level meta-pattern based on a special form of conceptual separation. The idea is that the ‘factual/transactional’ aspects of your application are held on one side, while the ‘visual/interactive’ aspects are held at another side. Another layer (Controller) mediates between the two.

You bet such a high level, conceptual degree of separation would be open to debate and interpretation – how about the age old debate between form and content? For this reason, and because there are least 6 other ways to separate your applications, MVC is not a software  pattern, just a meta-pattern.

This means that you’ll likely run in trouble if you just ‘try to use it’ without a little more design and preparation.

This also means that there are many ways  to define an ‘instance’ of MVC. Such instances include both strategies and frameworks; PureMVC is an MVC framework – on this note, don’t expect PureMVC to resolve all your problems – depending on what you are trying to do, PureMVC will either be supportive, or unsupportive.

What is PureMVC?

PureMVC is two things:

• A flexible, comprehensive framework ported across several languages.
• An open source software product, developed, supported and documented and promoted by a company.

From the above, there are immediate consequences:

1. Flexibility means that PureMVC can be supportive and unsupportive in a variety of ways – Supportive because it can be tailored to some of your needs; unsupportive because not all the design effort involved in defining a framework has been done for you, and you’ll get hurt if you don’t finish the job.
2. Comprehensive means that PureMVC covers, at framework level, most of the aspects involved in instanciating the MVC meta-pattern. This means that development using PureMVC is less error prone (than if it relied on more conventions) and results in code that often lacks concision and elegance.
3. Because PureMVC has been designed to be portable, it relies on a low common denominator between several languages. For this reason, it is probably a good investment if you’re navigating between languages and somehow despicable in consideration of facilities offered by specific languages.
4. Because PureMVC is actively promoted by a profit driven organization, it is hyped and tends to make promises that it doesn’t always fulfill. Business orientation may also be the reason why the PureMVC documentation combines sophisticated, obfuscated terminology with lengthy, uninformative explanations. So far, this may have proved to be a fair marketing choice, because PureMVC seems increasingly successful – which in the end benefits all its users.
5. Because PureMVC is open source, you can modify it in some ways and make it more suited to your needs if you really have to.

OK, but what is it?

PureMVC is a ’5 tier 3 tier framework with a facade’:

• Proxies are your model objects.
• Mediators are your view objects.
• Commands realise your controller as a collection of short lived, single responsibility classes (first good thing)
• Components are platform level, view side delegates typically shipping as part of a UI toolkit (Swing, Flash components etc…) and independant from PureMVC.
• Data objects are… …just data. They are also independant from PureMVC and originate either in your efforts at modelling your business domain or into an API provided by a third party. Data objects are, like proxies, part of your model.
• The Facade is a kind of registry/communication interface between your model, view and controller.

Proxies, Mediators and Commands communicate in two ways:

1. Notifications. These are (potentially) heavyweight messages holding untyped content transiting via the facade. Basically you wrap data into an instance of an IMessage interface, pass it to the facade it gets dispatched to other actors in your application. Then you unwrap your message, type content back (if you’re using a typed language) to whatever you expect it originally typed to, and do some processing. I dare hope you’re not thrilled.
2. Function calls. You retrieve an actor from the facade (any actor) and invoke functions on it. If you’re using a typed language, you can use typed arguments (but you lose logical separation).

Now is a good time to visit the PureMVC website and fetch their pretty diagram.

OK, since you’re back I’ll point out right away that ’5 tier 3 tier’ should arouse suspicion. Let’s get sober and clarify this bit:

• The model consists in Proxies and Data objects.
• The view consists in Mediators and Components
• Commands are mmh… just commands, and realise your controller.

Right, what’s going on here is additional separation, at a cost and with potential benefits. Some of the benefits go to the people that designed the framework; you maybe interested by the remaining benefits:

• Since PureMVC aims at being comprehensive and portable, it provides interfaces and default implementations for proxies, mediators and commands. Providing default implementations atop existing library components would be difficult or impossible, although developers may do that on a case basis. So 5 tiers allows to provide a product that is more complete and thus appears more attractive.
• Given that a lot of your  application level code is separated from language/platform/domain specific entities, your application is more portable. This means you can migrate it fairly easily to a different platform – this advantage is (to a limited extent) symmetric with the fact that the framework is easy to port across languages – but then, whereas it  is definitely a strength for the framework (as a product) to easily port across languages, how likely is it that we’ll want to port our application to another platform? How often does this converge with a genuine business concern?
• It is probably the case that maintaining a level of separation between library/platform and application specific code increases clarity.

What are the benefits of PureMVC?

• Commands – since I started writing commands, I stopped asking ‘whatever control might be’. Whenever you want an interaction between view and model, you instanciate a command, retrieve view and model actors (or fire notifications at them) and ‘do a job’. Once that is done your command gets garbaged collected. While this last bit, per se, may prohibit your using the framework as is (high rates of garbage collection may kill your application), it warrants that you won’t be holding references to data or view objects for longer than reason, or worse, storing information in controllers and nowhere else, which ‘sort of naturally’ happens if you don’t have commands. Commands also make it very clear, at project browser level, what is being done by your application – kind of silly but commands and IDEs, which aren’t great at presenting information visually and concisely, seem to fare well together.
• 5 tier 3 tier. If…  (a)you’re writing an application on your own, (b)you know the platform well, (c)you won’t reuse your business model (‘data’), (d)have no intention to use concurrent UI presentations of your data and (e)aren’t planning on porting your application to several languages and platforms, then 5/3 isn’t for you. But as you can see that’s many conditions. 5/3, originally, really put me off. Practically, this currently saves me a lot of time and worry as I’m specifying the ’3 tier core’ (proxies, mediators, commands) of a medium size application, atop a platform I know little, using a language variant I have never used before.
• Interfaces versus conventions. If you naturally lack discipline, are involved in teamwork and/or cannot enforce weaker conventions mechanically, interfaces warrant integrity at the cost of concision and elegance. This may slow you down (to jogging versus thrashing), irritate you and, overall define a day job versus programming fun. Mind that programming fun today might turn into a nightmare tomorrow.

What are the drawbacks of PureMVC?

• Untyped notification content. Providing a fully fledged ‘catch-all’ observer pattern implementation comes at a heavy cost. Event specific notification semantics (as provided by listener interfaces) are a nice to have. Typing rules maintainable applications versus wild mandragoras; casting is a pain.
  The boiler plate involved in registering listeners and writing notification interfaces makes me cringe every time, wishing I weren’t using a mainstream object language, and so forth but… I like to implement notification methods that deliver me explicit, typed arguments instead of a single, blackboxed instance. If you’re APIs are customer facing, I’d rather advise you don’t throw these notifications at them.
• Broadcast messages.  I hear that PureMVC notifications are channelled, but can’t really see the benefits. Increased flexibility versus reduced maintainability is integral to broadcast systems, and whether you want to use broadcast, unicast or a mix of both is a decision that should affect your choice of a framework
• Asynchronous control. If your application is ‘mostly modeless’ or you can’t afford multi-threading anyway, you’ll have to live with a lot of book-keeping.
  Multi-threaded or not, most UI frameworks nowadays are event driven (enforcing modal controllers against and event driven UI framework is a special skill). The problem isn’t there. The problem is that we tend to store transient data into semi permanent controllers. So yes, commands are safe, but they do require re-thinking control.
• Singleton facade. Unless you’re writing applications too small to consider feature oriented modularity (not the common case) you’ll have to either (a)unravel the mysteries of Multiton PureMVC or (b)find a workaround (there are some) or (c)experiment with a crowded broadcast messaging context (please don’t).

Is it worth it?

That depends mostly on the professional context you are evolving into, and a little bit on your programming experience:

• If you’re not doing a lot of team work and can demonstrate some discipline, maybe you just don’t need a framework – especially not a low common denominator framework at the language level. This is because frameworks tend to kill concision and elegance and you can instanciate the MVC meta-pattern using conventions.
• In my office, we chose PureMVC in part because we felt it would warrant increased code integrity (PureMVC is a framework and we are a 20 strong team with a lot of thrashing and no TDD), in part because we came to like 5/3, and in part because our guys are enthusiastic about the framework – plus it’s fairly popular in our waters, so it’s good for professional development.
• At home – at OOgtech – I won’t stand lack of concision and elegance. Putting the emphasis on feature separation versus layering is proving to support a very fast development/release cycle, while PureMVC  not only emphasizes layering, but also demotes modularity in its singleton implementation.
• Let’s face it – writing a separation framework requires expertise, not time or staff resources. The best framework, from a technical point of view, is probably an adaptation of something that already exists. So if you’re not worried about fostering the professional development of your employees and you’re after high productivity versus fads, PureMVC will just be one of several choices – and the best choice may often involve developing your own framework.

Summary

PureMVC is a well structured MVC framework. It boasts a couple of serious advantages – 5/3 tier structure, excellent separation using commands. It may not be the best choice if you’re after a very fast development/release cycle and could have benefited templated, typed notifications versus a catch-all observer pattern implementation.
This framework is commendable for small to large applications involving few modules and many loosely coupled interactions across a small number of interactors.

PureMVC may seduce developers looking for an MVC instance available across several languages and (as a front end developer) may look good on your CV (at least for now). While it may be too heavy for novice developers to learn, it is fairly integer and I would recommend it to developers with prior, untutored experience in instanciating the MVC meta-pattern.

Naive parsing techniques – part I

In this post, I’m considering a design for a simple tool that could help doing the following:

• Repackaging classes; this will involve replacing package and import declarations
• Validating class dependencies
• Generating code and TODO annotations from an incomplete specification
• Tracking high level aspects of system architecture by extracting relevant data from program code

Looking at the above, we’d surely agree that some kind of API would be required to take care of source analysis. This is where naive parsing comes in play.

If we needed an API to help resolve the above tasks unambiguously, we would also need to parse the source code reliably. However, writing parsers is overkill. In fact, just setting up and integrating with a parser might be quite a stretch.

Instead of going the full stretch, I’m proposing to write a naive parsing library. This will consist in several utility methods allowing to scan source files, detect relevant code fragments with a high (not absolute) degree of confidence and add/modify source files.

Why naive parsing?

I’ve already given half of the answer: parsing is expensive. Using naive parsing functions will allow my reusing the same techniques across similar languages. We’ll not only be saving time preparing the parsing facilities – we’ll actually save time every time we need to write another utility. That’s where ‘naive’ comes in play.

Most parsers somehow relate to the way we model language. However, there are strong smells indicating that parsers do not quite interpret text as we do:

• Classic parsers do not usually integrate error correction. When reading text, we are performing a mix of interpretation and error correction
• Given correct input, however complex, a classic parser will resolve that input into a parse tree of arbitrary depth and breadth. When reading text, we can easily overload when a sentence becomes too long and too complex.

Parsers, then, provide fail-fast, scalable solutions. Scalability is definitely a quality, but comes at a cost – naive parsing consists in simple rules that are easy to come up things, whereas writing scalable parsing rules is an art. Fail-fast may or may not be a quality depending on the context. For example, we might want our utilities to correct simple mistakes, even if that means introducing another mistake from time to time. After all, our code will eventually get either interpreted or compiled, so we only want to make sure that our automations generate an overall reduction in development cost.

Isn’t 100% reliability a paramount requirement?

Yes, but not in the parser used by our utilities. We need %100 reliability in the final product – what our utilities are helping us build – in contrast, we only need our utilities to save more time than they cost. In this particular scenario (considered the originally suggested applications), three strategies will be used to achieve correct results using only a ‘mostly accurate’ parser.

1. Simple, readable code. Simple, readable code is advocated everywhere. This suggests that parsers that allow very complex code – code that humans find hard or impossible to read – are too powerful. In short, we’ll agree to rewrite some of the code that the parser cannot read wherever this arguably increases the readability, simplicity and maintainability of the source.
   
2. Semantic separation. As we’ll see later, a naive parser often fails to analyze correctly code that uses semantic overlaps. Semantic overlaps don’t really promote simple code, and need rarely occur in program code, although classic parsers often rely on very limited semantic separation – for example very limited number of language keywords.
3. Patches. We will allow defining patches that determine project specific exceptions to the parsing process. This will be provided as an ultimate measure, mostly used to deal with legacy code that cannot be modified.

That’s all folks

Here’s a plan. Yes, I do have something concrete in mind, but if you read this post, I’ll be delighted to get feedback and hear that this has inspired ideas that have nothing to do with what I envision

PureMVC / F* Beauty and the Beast Primer

Right. That’s what I’m doing at my job at the moment.

PureMVC can be pretty useful in some cases, although I feel pretty sobre about it. In fact, trying to choose a framework for our next game engine has probably had a knock-on effect eventually leading to my proposing the F* meta-pattern and risking the ee-xml project on it.

You can read about F* on this blog. What you can’t read about yet is that F* seems to be working out pretty well. I derived an architecture from F* (CSFA, for compile safe feature architecture). I’ll explain that later – or sooner if somebody actually asks.

I need to defer explaining in detail a number of good and bad things about PureMVC. Frameworks aren’t really hard to explain – mind, it’s been pointed out to me rightly that the hard question is whether a framework will or will not promote good code in a team environment – but it’s not really something for the 1-2am timezone. Now here’s a few hints if you’re facing the same kind of choices. These hints are pretty general and probably go beyond PureMVC or F*.

• PureMVC uses commands to realise it’s controller. A command is a disposable, objectified function that can access both model and view. This is by far the most obvious strength about the framework. Rather than desperately trying to keep data and view information out of the controller, we agree that control is volatile, which constrains view and model to integrity while empowering the control layer. But then, you don’t need PureMVC to use commands.
• PureMVC has deliverables and business support. In other words, it is a product. The deliverables aren’t many and the authors are intent on hyping their work.
• PureMVC is designed as a ubiquitous, lowest common denominator framework. If you love your language; if you love typing; if you love elegance, then you might not actually like PureMVC. I heard that porting PureMVC apps across languages is a breeze. No wonder. I hope not too many teams face the prospect of switching language halfway a project.
• Separation can exist at different levels. In particular, separation at compile time doesn’t imply separation at runtime. It is relatively easy to use PureMVC in such a way that you end up with a lot of type-casting (runtime hazards) without actually separating application tiers (in other words, there is sometimes a strong incentive for importing types from one layer to another). You can do a jolly mess with PureMVC. Really.
• PureMVC uses commands and a heavyweight notification scheme. This makes it extremely verbose. Verbosity means that your code has quite a bit of inertia. Inertia is bad.

This is why I need to take time to analyze and explain what design choices in creating a framework actually entail. PureMVC isn’t bad, but frankly speaking an OTS framework has little chances to be optimal for any given project, and I hope I can explain why.

If you can’t sleep, here’s a powerful mantra:

Type casting is bad.
Type casting is bad.
Type casting is bad.

….zzz