Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Scala Port  (Read 11931 times)
dorcsinecz
Newbie
*
Posts: 3


View Profile Email
« on: October 15, 2009, 03:09:59 »

Hi Guys,

I rewrote the PureMCV framework in Scala language, but I have some questions/problems.
Previously I was using the multicore java version, which worked well with scala,
but because of it inherent one thereadedness I quicly hit a bottleneck (I'm wirting a server application)
In scala I also tried Actors but the only way you can send a message to an actor is by having a reference to the instance,so that is clearly not a modular architecture (and I do not want to pollute my code with singletons either..)
So I thought I will rewrite the PureMVC framework with Scala Actors (every actor is a real or virtual (pooled) thread) My plan was to run all mediators, commands and proxies in their own thread. But this of course posed a lot of questions.
Firstly: you cannot touch the proxies from the commands or the mediators because that is not thread safe, so you cannot do this:
:
var med = facade.retrieveMediator(TestMediator.NAME).asInstanceOf[TestMediator]
med.doSomething();
Basically you cannot call directly from any class instance to any other instance (by instance I mean commands, mediators and proxies)
For these purposes I created the bangWait function, which works very similary to the above, though not by locking but by sending scala !? message
Secondly: actors must have been told what notifications will they recat on (just like in the handleNotification function in Mediators)
but this will not work for proxies since they do not listen to notifications.
Thirdly: actors have ! and !? (and !!) operations, so I had to implement more functions like sendNotification to represent these

My solution to these problems:
-I ported the multicore AS3 version (it's much closer to scala sintax than java)
-All test cases were ported too and are running ok
-I completely removed proxies for the time being I use Mediators instead of them(see above in second point)
-All other stuff remained the same, I tried to keep as much of the original structure as possible.
-in the Notifier class besides the 'sendNotification' method a new 'bang' and a new 'bangWait' method was included
 as it is in the Notifier it can be used from Commands and Mediators too. The bang method gets converted in the Observer class to  scala ! and (it's just like sendNotification but with actors). The bangWait method (scala !?) is the equvivalent of a sychronous function call (see the scala Actors documentation for more info on this)
-In the mediator if you do not handle actor generated notifications with handleNotification function but by overriding the scala act method,  you can send a reply with the scala reply method.
-As command listen to only one notification in any case the execute method will be called (so command remain 100% untouched)
-I wrote some extra testcases to test Actor based testcases.

I'm willing to commit the code if anyone interested, but I do not know what to do about all these changes. As of now ,except for proxies I left everything untouched, all I added -besides porting - are extra functionality , but if a newcomer wants to use it I would remove many standard
stuff from puremvc because those are not thread safe operations anymore.. remember all puremvc classes are running in thir own thread!
So I'm not sure if all these changes will qualify as PureMVC for Cliff Hall ...
It's more like a tiny but enormouly scalable messaging framework ... ParalelPureMVC or something.

I guess none of the above makes too much sense if you do not know Scala, but anyway , any comments? ideas?

I attached some testcases
« Last Edit: October 15, 2009, 03:13:00 by dorcsinecz » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: October 15, 2009, 09:45:35 »

You are correct, not knowing Scala does make all this pretty hard to understand.

Also I wasn't able to view the files in the zip.

-=Cliff>
Logged
dorcsinecz
Newbie
*
Posts: 3


View Profile Email
« Reply #2 on: October 15, 2009, 11:17:23 »

Yeah, so my main question here for you Cliff: should I send you the project and host it here or should I put it on e.g.: google code and call it something else? I do not want to confuse people ...

changes necessary as I see it now:
  • retreiveMediator should be removed for thread safety
  • retreiveProxy should be removed for thread safety
  • The proxy class should be removed since retreiveProxy is not possible and proxies do not listen to notifcations, ergo the only way to retreive data from elswhere is by sending notfications. The proxy class should be a subclass of the mediator class, so it can listen to notifications
  • The sendNotification or handleNotification should be removed or I can keep them but then I will replace the underlyeing implementation
  • If you want to listen to notifications then the Mediator has to have an act method because Mediator is a extending the Scala Actor class too
  • bang(async) and bangWait(sync) methods for sending notifications
Probably there are some other things, it was a week ago now since I finished...

So is it pureMVC or not?  ;)
Logged
dorcsinecz
Newbie
*
Posts: 3


View Profile Email
« Reply #3 on: October 15, 2009, 11:19:37 »

The zip file:
I downloaded and extracted it sucessfully...
There are 9 .scala files in it.
I made it with TotalCommander on WinXP
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #4 on: October 15, 2009, 01:28:04 »

The reason that it's sort've important for things to work essentially the same on every port (except of course for the syntatic sugar of the target language) is that it makes relatively straightforward porting of implemented applications possible as well. If the entire underlying premise of the framework is similar for a given PureMVC port X, then when trying to port your implementation code from PureMVC port Y, you have the same actors with the same roles, responsibilities and collaborations. It should be a relatively straightforward thing to do, except at the boundaries of the app (view components / services ). But the mediators and proxies and commands and facade and notifications should all remain constant. You shouldn't have to rethink the internal traffic of your app. Also, the similarity between ports helps the central best practices to apply broadly.

Concerning thread safety, you should perhaps talk with Andy Adamczyak, the C# port owner. He was able to handle thread safety issues without radically altering the framework. The differences between threaded and non-threaded environments mainly have to do with synchronizing methods and the like.

If you could send me a zip with the actual framework to cliff at puremvc dot org, I'll take a look at it and try to see what I can find out about Scala regarding the differences. But the point with the framework is to try and adapt it to the target language without altering the basic way that you use it. We've tried to stick with the simplest language constructs everywhere in order to help facilitate this. So far this hasn't been a real problem, but Scala may simply be 'too different' from most OOP languages for this to happen.

If it really needs to be modified so drastically (dropping Proxies, no sendNotification and handleNotification, etc), then you might indeed have something less like PureMVC and more like a messaging system inspired by PureMVC.

-=Cliff>
« Last Edit: October 15, 2009, 01:36:03 by puremvc » Logged
Pages: [1]
Print