when we run out of characters
Hi! We have a namespace problem. As PHP identifiers can have only letters, numbers and underscores we are using underscores for the hook identifier, ie. we have a hook_menu etc. On the other hand, when a module is best described with more than one word, the words are separated by underscores. This can lead to clashes, like foo.module defines a function called foo_bar_that and when foo_bar.module would like to implement the newly introduced hook_that.... then we have a problem. This already means that if you have a foo.module then you are better not using any function that's called foo_X_hookname. We discussed several solutions on IRC. One of them is using double underscores somewhere. But where? If you use them as hook identifiers you have 35K LoC in core to look through (and change a significant percentage). It will be fun, fun, fun! It's visually very confusing to rename taxonomy_menu to taxonomy__menu because then the hook_menu will look like taxonomy__menu_menu and the two menus look as if they belong together. So, that won't work. Another solution is to use zero underscores somewhere. But where? Again, changing core is not a good option, and I won't like hookmenu instead of hook_menu. So, with perfect logic we arrived to a very ugly point: we shall rename axonomy_menu to taxonomyMenu . Do I like this? _No_! But... Regards NK
So, with perfect logic we arrived to a very ugly point: we shall rename axonomy_menu to taxonomyMenu . Do I like this? _No_! But...
Eeeeek ... Do you mean all contrib will have to change so module names have no underscores in them? CamelCaseSucks and will be inconsistent with everything else in Drupal ...
Karoly Negyesi wrote:
Hi!
We have a namespace problem. As PHP identifiers can have only letters, numbers and underscores we are using underscores for the hook identifier, ie. we have a hook_menu etc.
On the other hand, when a module is best described with more than one word, the words are separated by underscores. This can lead to clashes, like foo.module defines a function called foo_bar_that and when foo_bar.module would like to implement the newly introduced hook_that.... then we have a problem. This already means that if you have a foo.module then you are better not using any function that's called foo_X_hookname.
I don't think this is a real problem. The number of hooks isn't all that big so you can easily work around it. This is the kind of API change even I don't need. Cheers, Gerhard
Gerhard Killesreiter wrote:
I don't think this is a real problem. The number of hooks isn't all that big so you can easily work around it.
This is the kind of API change even I don't need.
I concur. I think we're better off using api.module to publish a list of hooks and saying "Please avoid ending your function names with these hooks, Just In Case."
On May 16, 2006, at 3:15 PM, Earl Miles wrote:
Gerhard Killesreiter wrote:
I don't think this is a real problem. The number of hooks isn't all that big so you can easily work around it. This is the kind of API change even I don't need.
I concur. I think we're better off using api.module to publish a list of hooks and saying "Please avoid ending your function names with these hooks, Just In Case."
This has nothing to do with hooks, actually. It has to do with function names. There are 22 modules called "taxonomy_something" in contrib alone. If taxonomy.module adds a function that begins with any one of those "taxonomy_something"s, then a module breaks. It doesn't matter whether or not that function is a hook. This isn't a big problem right now. It could become one in the future. We should come up with a convention now that will prevent matters from getting worse later.
Can the simple solution be forbidding module names to have under scores in them? So, taxonomy_menu becomes taxonomymenu (CamelCaseSucks). For new modules, it is easy to enforce (e.g. project/cvslog module can refuse to add it), but for existing ones, work is needed.
On May 16, 2006, at 3:35 PM, Khalid B wrote:
Can the simple solution be forbidding module names to have under scores in them? So, taxonomy_menu becomes taxonomymenu (CamelCaseSucks).
For new modules, it is easy to enforce (e.g. project/cvslog module can refuse to add it), but for existing ones, work is needed.
I don't think things are broken to the point that we need to change existing modules. I just want some codified guidelines to point at when coming up with new module names.
Khalid B wrote:
Can the simple solution be forbidding module names to have under scores in them? So, taxonomy_menu becomes taxonomymenu (CamelCaseSucks).
This strikes me as an excellent idea. If some contrib developer wants to use CamelCase we cant stop him anyway.
For new modules, it is easy to enforce (e.g. project/cvslog module can refuse to add it)
Easy to add.
, but for existing ones, work is needed.
We can leave existing ones as they are, I think. Cheers, Gerhard
Here is the simplest solution that will work going forward. The current modules in their present incarnation have no issues, and the new naming scheme (allow only lower case letters and numbers, and disallow underscores) will prevent new ones from having name space clashes. There was one +1 on this from Gerhard. Any other objections? On 5/16/06, Khalid B <kb@2bits.com> wrote:
Can the simple solution be forbidding module names to have under scores in them? So, taxonomy_menu becomes taxonomymenu (CamelCaseSucks).
For new modules, it is easy to enforce (e.g. project/cvslog module can refuse to add it), but for existing ones, work is needed.
You mean we're not going to add underscores to all the hooks? eg. module__hook() I should have spoken up earlier dammit! Khalid B wrote:
Here is the simplest solution that will work going forward.
The current modules in their present incarnation have no issues, and the new naming scheme (allow only lower case letters and numbers, and disallow underscores) will prevent new ones from having name space clashes.
There was one +1 on this from Gerhard.
Any other objections?
On 5/16/06, Khalid B <kb@2bits.com> wrote:
Can the simple solution be forbidding module names to have under scores in them? So, taxonomy_menu becomes taxonomymenu (CamelCaseSucks).
For new modules, it is easy to enforce (e.g. project/cvslog module can refuse to add it), but for existing ones, work is needed.
I mean that instead of: module_name It will just be: modulename Then the underscore will be a hook separator. modulename_hook1 That is it. On 5/17/06, sime <info@urbits.com> wrote:
You mean we're not going to add underscores to all the hooks? eg. module__hook()
I should have spoken up earlier dammit!
Khalid B wrote:
Here is the simplest solution that will work going forward.
The current modules in their present incarnation have no issues, and the new naming scheme (allow only lower case letters and numbers, and disallow underscores) will prevent new ones from having name space clashes.
There was one +1 on this from Gerhard.
Any other objections?
On 5/16/06, Khalid B <kb@2bits.com> wrote:
Can the simple solution be forbidding module names to have under scores in them? So, taxonomy_menu becomes taxonomymenu (CamelCaseSucks).
For new modules, it is easy to enforce (e.g. project/cvslog module can refuse to add it), but for existing ones, work is needed.
On May 16, 2006, at 12:13 PM, Gerhard Killesreiter wrote:
The number of hooks isn't all that big so you can easily work around it.
but as we've recently agreed, the hooks can, do, and will change. when JonBob added "taxonomy_menu.module", there's no way he could have known in advance that hook_menu() was coming in the future. we *certainly* aren't going to tie our own hands as to what hooks should be called in the future because of legacy modules with once-happy-now- conflicting names. ;) On May 17, 2006, at 9:06 AM, Khalid B wrote:
Any other objections?
my only objection to modulename_hook() is that it will be ugly and harder to read for the humans (e.g. on the admin/modules page, in the code itself, etc). for example, the date field module for cck would become something like "fielddate". if there's no other alternative, personally, i'd prefer fieldDate. *ducks* module_name__hook() is probably the cleanest option, and closest to existing code standards. but, that requires changing *A LOT* of code. :( too much code IMHO to be worth it, as "elegant" as it might be. moduleName_hook() introduces case, but i think is fairly easy to read. this has the nice benefit of only effecting modules that want multiple words in their own name, instead of forcing all code to change. modulename_hook() is also ok from the code side, but then harder to read for the humans. module_name_hook() is the status quo, and vulnerable to trouble down the road, especially since it's impossible to predict in advance what hooks are going to be in use N drupal versions from now. as JonBob pointed out, it's not just a problem of core hooks, but function names in the "parent" modules (e.g. og.module) that have a bunch of "children" modules (og_*). last time i brought this up, killes was quick to scold me with "this is not relevant to core". ;) at some level, that's true, in that there are no core modules that want/need multiple words in their name. however, once CCK gets into core, this will be more of an issue (unless you want to open the new can of worms about grouping modules into classes that can be downloaded and administered together... something like propagating the module taxonomy in use on drupal.org directly into the administrative interface some how -- yikes). and, in general, i'd be nice to have a documented, reasonable policy/convention for this, so that as contrib modules are developed that run into this problem, we'll know what to do. personally, moduleName_hook() (for the handful of modules that care, e.g og, cck, etc) isn't the end of the world, and requires much less work. code may be gold, but grunt-work code is lead, IMHO. -derek
modulename_hook() is also ok from the code side, but then harder to read for the humans.
We only see the modulename now at e.g. admin/modules because we lack methods for setting titles and rely on filenames. When, with a new install system, we get metadata files, I expect this issue largely will disappear.
On May 17, 2006, at 3:15 PM, Nedjo Rogers wrote:
We only see the modulename now at e.g. admin/modules because we lack methods for setting titles and rely on filenames. When, with a new install system, we get metadata files, I expect this issue largely will disappear.
very true. however, it'd still be ugly and hard to read in the code, and i don't mind us optimizing for the developers, too (see dries's comments about making/keeping drupal easy to develop for). also, if we had a better admin interface, then we could just leave it called "date.module" and let something else worry about grouping it with all the other field-type modules. ;) however, we don't have this new installer/admin interface yet. however, we do have the potential namespace conflict already (and the problem of CCK modules not being grouped in any sane way). again, not exactly "relevant to core", but this list isn't *just* about core, either. ;) -derek
Derek Wright wrote:
it'd still be ugly and hard to read in the code, and i don't mind us optimizing for the developers, too (see dries's comments about making/keeping drupal easy to develop for).
It will be actually easier to develop because you don't have to wrack your brain about how to name your functions in "super magic" module, we just provide rules about only allowing alphanumeric in module names. The modules directory will also look cleaner without underscores :) I can't believe something this simple is taking so much debate.. Someone just pull the trigger! haha -Rowan
Any other objections?
my only objection to modulename_hook() is that it will be ugly and harder to read for the humans (e.g. on the admin/modules page, in the code itself, etc). for example, the date field module for cck would become something like "fielddate".
If we have a hook_info, then we can put any module name in it, like we do with node type modules today. Or, when we get the metadata files for each module, we can have a human friendly description in it.
if there's no other alternative, personally, i'd prefer fieldDate. *ducks*
[Throws TV remote at dww ...]
moduleName_hook() introduces case, but i think is fairly easy to read. this has the nice benefit of only effecting modules that want multiple words in their own name, instead of forcing all code to change.
It introduces Yet-Another-Variant-In-Code-Style in Drupal. This will be more confusing for everyone.
personally, moduleName_hook() (for the handful of modules that care, e.g og, cck, etc) isn't the end of the world, and requires much less work. code may be gold, but grunt-work code is lead, IMHO.
I can't say it is the end of the world, but then it would be too confusing. Our code style discourages camel case, and now we will have yet another exception ...
I have another suggestion - and this time it's a serious one. How about changing it so that we literally put the word 'hook' into all hook implementations? So whereas now we have: function user_menu() Instead we would have function user_hook_menu() This format has a number of advantages, IMO, over some of the other suggestions put forward: - No new naming conventions that are currently non-standard in Drupal (e.g. camelCase, double__underscores, totallyunseparatedwords). - Makes it VERY clear what is a hook implementation, and what is just another function in a module (e.g. many modules have a foo_form() function, which is not an implementation of hook_form() - these would become distinguishable from foo_hook_form() functions). Of course, it still has the disadvantage of thousands of LOC needing to be changed if we implement it. Which is why I think we really need to consider whether our need is that urgent, that it warrants so much effort being put into fixing up our function naming. Cheers, Jaza. On 5/18/06, Khalid B <kb@2bits.com> wrote:
Here is the simplest solution that will work going forward.
The current modules in their present incarnation have no issues, and the new naming scheme (allow only lower case letters and numbers, and disallow underscores) will prevent new ones from having name space clashes.
There was one +1 on this from Gerhard.
Any other objections?
On 5/17/06, Jeremy Epstein <jazepstein@gmail.com> wrote:
I have another suggestion - and this time it's a serious one. How about changing it so that we literally put the word 'hook' into all hook implementations?
So whereas now we have: function user_menu()
Instead we would have function user_hook_menu()
That is an idea that is worth exploring. The amount of work that is needed is similar to the double underscore thing. It has an advantage where hook means hook. We often get newbie developers confused on what a hook is in the first place. This can help with the learning curve (e.g. grep/search all modules for _hook_ to see what hooks get fired, ...etc.)
On 5/17/06, Khalid B <kb@2bits.com> wrote:
On 5/17/06, Jeremy Epstein <jazepstein@gmail.com> wrote:
Instead we would have function user_hook_menu()
That is an idea that is worth exploring. The amount of work that is needed is similar to the double underscore thing.
It has an advantage where hook means hook. We often get newbie developers confused on what a hook is in the first place. This can help with the learning curve (e.g. grep/search all modules for _hook_ to see what hooks get fired, ...etc.)
This would be my preference. It would make it more obvious that the function implements a hook. I don't think I'm a total newb but I still sometimes find myself confused about what function are implementing a hook when scanning a new module.
Rewrite module_invoke() like this (1 line change to call_user_func_array args): function module_invoke() { $args = func_get_args(); $module = array_shift($args); $hook = array_shift($args); $function = $module .'_'. $hook; if (module_hook($module, $hook)) { return call_user_func_array(array($module, $function), $args); } } Similar change to module_invoke_all()... And then wrap each module in a Class named same as module, as previously suggested. shazam! :-) Or rename everything to *_hook_* using a really smart global search and replace. Maybe a little AWK script could do it... hmmm.
On May 17, 2006, at 7:20 PM, Jeremy Epstein wrote:
I have another suggestion - and this time it's a serious one. How about changing it so that we literally put the word 'hook' into all hook implementations?
So whereas now we have: function user_menu()
Instead we would have function user_hook_menu()
I like this idea. Extent code should be able to be fixed programatically (we have a finite list of hooks), and this method is self-documenting; it makes it clear which functions are hooks and which aren't. Ricky
On 5/18/06, Richard Morse <remorse@partners.org> wrote:
On May 17, 2006, at 7:20 PM, Jeremy Epstein wrote:
I have another suggestion - and this time it's a serious one. How about changing it so that we literally put the word 'hook' into all hook implementations?
So whereas now we have: function user_menu()
Instead we would have function user_hook_menu()
I like this idea. Extent code should be able to be fixed programatically (we have a finite list of hooks), and this method is self-documenting; it makes it clear which functions are hooks and which aren't.
I also +1 this idea which is better than mine (disallow underscore in module names). They are different solution though, one requires no work at all, and imposing the restriction in cvslog/project modules. The other requires changes to Drupal core as well as contrib (perhaps scripted ...) Depends on how severe we think this problem is, and whether it warrants change now ...
2006/5/18, Khalid B <kb@2bits.com>:
On 5/18/06, Richard Morse <remorse@partners.org> wrote:
On May 17, 2006, at 7:20 PM, Jeremy Epstein wrote:
I have another suggestion - and this time it's a serious one. How about changing it so that we literally put the word 'hook' into all hook implementations?
So whereas now we have: function user_menu()
Instead we would have function user_hook_menu()
I like this idea. Extent code should be able to be fixed programatically (we have a finite list of hooks), and this method is self-documenting; it makes it clear which functions are hooks and which aren't.
I also +1 this idea which is better than mine (disallow underscore in module names).
+1 from me as well. Reasons already stated above.
They are different solution though, one requires no work at all, and imposing the restriction in cvslog/project modules.
The other requires changes to Drupal core as well as contrib (perhaps scripted ...)
Depends on how severe we think this problem is, and whether it warrants change now ...
One could always make the change now to Drupal's code but still support hook functions without 'hook' - possibly disallow them from 4.8 and onwards? (Ie., allow both the way it is now and hook_hook in DRUPAL-4-7, and only hook_hook in HEAD - allowing people to migrate easily without having to change too much to remain compatible between 4.7 and 4.8 (I don't know what the policy is on this generally, so maybe it should only go in HEAD...).) But then, I've only just stumbled upon the discussion save a few tidbits I've picked up in #drupal - the above just makes sense to my sleep deprived head as of this moment. :) -- Frederik 'Freso' S. Olesen <http://freso.dk/>
The current modules in their present incarnation have no issues, and the new naming scheme (allow only lower case letters and numbers, and disallow underscores) will prevent new ones from having name space clashes.
There was one +1 on this from Gerhard.
Any other objections? No not really.
We can always discriminate which part constitutes the module name part and which constitutes the hook name part in a function name. What we need to agree is how to handle ambiguities. I would probably go with this suggestion. And mark everything which doesn't comply with it as "frozen" and maybe later as deprecated syntax. I a couple of releases thime the border cases will disappear. I hope. Cheers, Vlado
On Tue, May 16, 2006 2:30 pm, Jonathan Chaffer said:
On May 16, 2006, at 3:15 PM, Earl Miles wrote:
Gerhard Killesreiter wrote:
I don't think this is a real problem. The number of hooks isn't all that big so you can easily work around it. This is the kind of API change even I don't need.
I concur. I think we're better off using api.module to publish a list of hooks and saying "Please avoid ending your function names with these hooks, Just In Case."
This has nothing to do with hooks, actually. It has to do with function names. There are 22 modules called "taxonomy_something" in contrib alone. If taxonomy.module adds a function that begins with any one of those "taxonomy_something"s, then a module breaks. It doesn't matter whether or not that function is a hook.
This isn't a big problem right now. It could become one in the future. We should come up with a convention now that will prevent matters from getting worse later.
If you must camelCase something, wouldn't camelCasing the module name be less painful than the hook? There's at least fewer of them, I believe. Vis, easier to rename 22 taxonomy_something to taxonomySomething than to rename 2200 hook_something to hookSomething. --Larry Garfield
Let's just turn every module into a static class, and change the whole hook system to call namespace-contained methods rather than plain functions. * ducks for cover... Take it easy, people - that was a JOKE! Cheers, Jaza. On 5/17/06, Karoly Negyesi <karoly@negyesi.net> wrote:
Hi!
We have a namespace problem. As PHP identifiers can have only letters, numbers and underscores we are using underscores for the hook identifier, ie. we have a hook_menu etc.
On the other hand, when a module is best described with more than one word, the words are separated by underscores. This can lead to clashes, like foo.module defines a function called foo_bar_that and when foo_bar.module would like to implement the newly introduced hook_that.... then we have a problem. This already means that if you have a foo.module then you are better not using any function that's called foo_X_hookname.
We discussed several solutions on IRC.
One of them is using double underscores somewhere. But where? If you use them as hook identifiers you have 35K LoC in core to look through (and change a significant percentage). It will be fun, fun, fun! It's visually very confusing to rename taxonomy_menu to taxonomy__menu because then the hook_menu will look like taxonomy__menu_menu and the two menus look as if they belong together.
So, that won't work.
Another solution is to use zero underscores somewhere. But where? Again, changing core is not a good option, and I won't like hookmenu instead of hook_menu.
So, with perfect logic we arrived to a very ugly point: we shall rename axonomy_menu to taxonomyMenu . Do I like this? _No_! But...
Regards
NK
Jeremy Epstein wrote:
Let's just turn every module into a static class, and change the whole hook system to call namespace-contained methods rather than plain functions.
* ducks for cover... Take it easy, people - that was a JOKE!
Cheers, Jaza.
Hey, that works for me! No matter what system we use, there'll be potential problems, thanks to PHP's lack of namespace capabilities outside of classes. :-(
Chris Johnson wrote:
Jeremy Epstein wrote:
Let's just turn every module into a static class, and change the whole hook system to call namespace-contained methods rather than plain functions.
Hey, that works for me!
No matter what system we use, there'll be potential problems, thanks to PHP's lack of namespace capabilities outside of classes. :-(
That may be a joke, but it isn't actually that horrible of an idea. I realize people'd never go for it but it *does* solve the namespace issue nicely.
On 5/17/06, Earl Miles <merlin@logrus.com> wrote:
Chris Johnson wrote:
Jeremy Epstein wrote:
Let's just turn every module into a static class, and change the whole hook system to call namespace-contained methods rather than plain functions.
Hey, that works for me!
No matter what system we use, there'll be potential problems, thanks to PHP's lack of namespace capabilities outside of classes. :-(
That may be a joke, but it isn't actually that horrible of an idea. I realize people'd never go for it but it *does* solve the namespace issue nicely.
Last year, I was crazy enough (and coerced enough) to write an OO fork of Drupal. You can look at the code, and read my conclusions about this experiment, if you want: http://drupal.org/node/37939 As I made quite clear on this page, I don't think that Drupal core should ever try this. ;-) Cheers, Jaza.
Jeremy Epstein wrote:
On 5/17/06, Earl Miles <merlin@logrus.com> wrote:
Jeremy Epstein wrote:
Let's just turn every module into a static class, and change the whole hook system to call namespace-contained methods rather than plain functions.
That may be a joke, but it isn't actually that horrible of an idea. I realize people'd never go for it but it *does* solve the namespace issue nicely.
Last year, I was crazy enough (and coerced enough) to write an OO fork of Drupal. You can look at the code, and read my conclusions about this experiment, if you want:
I don't know about making all of Drupal OO, but it seems straight-forward and simple to make all the hook calls be method calls, and each module be a class. That solves our namespace problem once and for all, and really makes very little structural change to Drupal. I may just look into it. ..chrisxj
On 17 May 2006, at 5:41 PM, Chris Johnson wrote:
I don't know about making all of Drupal OO, but it seems straight- forward and simple to make all the hook calls be method calls, and each module be a class. That solves our namespace problem once and for all, and really makes very little structural change to Drupal. I believe the issue we had was defining stuff in different namespaces from within the module.
Can one do : function theme::myhook($var, $var, $var) { } In php ? This might be less of an issue when we move to templates though, but there are still cases where we want to define a function in another namespace. Also, as Jaza said in his post, there's not really much of a gain to be had by this. as it's still not using constructors, or any of the other things objects are useful for. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
function theme::myhook($var, $var, $var) {
}
In php ? no. not on classes. php doesn't have prototype inheritance like javascript.
only on objects. and that is a bit weird because variables and functions/methods live (syntax wise) in different environments. that's why $object->$method() :(
Let's just turn every module into a static class, and change the whole hook system to call namespace-contained methods rather than plain functions. This does have a lot of merit - classes are the natural way to emulate namespaces in php.
The only real problem we have with that is include and require in code. It must be used in top level, AFAIK, in order for the class to be visible to everywhere, might be wrong. In php5+ this solution will give additional benefits long term. We will be able to use __autoload() to manage module includes automatically, rather than doing had checks. When/if drupal moves exclusively to php5 this will have a huge effect on code simplicity and possibly performance.
That may be a joke, but it isn't actually that horrible of an idea. I realize people'd never go for it but it *does* solve the namespace issue nicely. I concur.
On May 17, 2006, at 7:11 AM, Vladimir Zlatanov wrote:
The only real problem we have with that is include and require in code. It must be used in top level, AFAIK, in order for the class to be visible to everywhere, might be wrong.
I thought this was the case, and wrote about it in the OOP essay. However, I have not been able to reproduce it recently. A PHP version bump may have changed this behavior, or it may have been related to something more subtle in the xmlrpc.inc implementation (that's where the issue came up originally). I will probably amend the essay to remove this comment.
Jonathan Chaffer wrote:
On May 17, 2006, at 7:11 AM, Vladimir Zlatanov wrote:
The only real problem we have with that is include and require in code. It must be used in top level, AFAIK, in order for the class to be visible to everywhere, might be wrong.
I thought this was the case, and wrote about it in the OOP essay. However, I have not been able to reproduce it recently. A PHP version bump may have changed this behavior, or it may have been related to something more subtle in the xmlrpc.inc implementation (that's where the issue came up originally). I will probably amend the essay to remove this comment.
Classes were always in the global scope in PHP, so there should have been some specific problems in xtemplate. Gabor
The only real problem we have with that is include and require in code. It must be used in top level, AFAIK, in order for the class to be visible to everywhere, might be wrong.
I thought this was the case, and wrote about it in the OOP essay. However, I have not been able to reproduce it recently. A PHP version bump may have changed this behavior, or it may have been related to something more subtle in the xmlrpc.inc implementation (that's where the issue came up originally). I will probably amend the essay to remove this comment.
Classes were always in the global scope in PHP, so there should have been some specific problems in xtemplate. As far as I remember, the problems were due to new objects.
The namespace issue is not too severe to call for urgency. It will be good, if a solution can help having a clean code. A slight annoying problem with classes whould be that hooks, if translated directly, will become arrays, as opposed to simple strings. This is required for method callbacks. On the plus side, we can factor in a load per need, triggered on error, for example class not found. Which might reduce the memory use.
Guys ... All this migration to OO stuff is superfluous. Dries and a bunch of us are already working on OO Drupal in Java, and it will be ready for 5.1. More on http://groups.drupal.org/droopal So, let us continue that discussion there. ;-)
All this migration to OO stuff is superfluous. Dries and a bunch of us are already working on OO Drupal in Java, and it will be ready for 5.1.
More on http://groups.drupal.org/droopal
You are kidding! Just when I managed to convince a few bryght heads to port drupal to haskell. The code is about 80% there. All that is left is theming.
On 5/17/06, Vladimir Zlatanov <vlado@dikini.net> wrote:
All this migration to OO stuff is superfluous. Dries and a bunch of us are already working on OO Drupal in Java, and it will be ready for 5.1.
More on http://groups.drupal.org/droopal
You are kidding! Just when I managed to convince a few bryght heads to port drupal to haskell.
The code is about 80% there. All that is left is theming.
We have to prevent this duplication of effort, and parallel projects ... Gerhard, can you please revoke CVS access to the Bryght guys? I have Dries on my side on this ...
On Wed, May 17, 2006 10:20 am, Khalid B said:
On 5/17/06, Vladimir Zlatanov <vlado@dikini.net> wrote:
All this migration to OO stuff is superfluous. Dries and a bunch of us are already working on OO Drupal in Java, and it will be ready for 5.1.
More on http://groups.drupal.org/droopal
You are kidding! Just when I managed to convince a few bryght heads to port drupal to haskell.
The code is about 80% there. All that is left is theming.
We have to prevent this duplication of effort, and parallel projects ...
Gerhard, can you please revoke CVS access to the Bryght guys? I have Dries on my side on this ...
It's nice to know that we still haven't come close to running out of "characters" around here. *ducks from flying tomatoes* --Larry Garfield
We have to prevent this duplication of effort, and parallel projects ... That's part of the translation process. Translate not only to human but to other computer languages
Gerhard, can you please revoke CVS access to the Bryght guys? I have Dries on my side on this ... Gerhard, don't - it was your idea in the first place :)
The only real problem we have with that is include and require in code. It must be used in top level, AFAIK, in order for the class to be visible to everywhere, might be wrong. Correction: classes have global scope, regardless of the scope in which include or require is called
participants (19)
-
Adrian Rossouw -
andrew morton -
Chris Johnson -
Derek Wright -
drupal -
Earl Miles -
Frederik 'Freso' S. Olesen -
Gabor Hojtsy -
Gerhard Killesreiter -
Jeremy Epstein -
Jonathan Chaffer -
Karoly Negyesi -
Khalid B -
Larry Garfield -
Nedjo Rogers -
Richard Morse -
Rowan Kerr -
sime -
Vladimir Zlatanov