Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.]

Jordan K. Hubbard jkh at apple.com
Sat Aug 22 19:09:17 PDT 2009


That's it in a nutshell.  None of us thought that Tcl was the most  
popular/best/cromulent scripting language around (all the accusations  
I get of being a Tcl fan-boy aside :), and if we'd wanted people to be  
exposed directly to the language on a daily basis we would probably  
have actually chosen Ruby as the implementation language and followed  
the newest hotness.  Our primary goal, however, was to be able to  
express ports as simple key/value pairs for the majority case, the  
minority/complex cases involving hopefully only small snippets of  
actual "code".

That said, there's no reason that a Portfile needs to written in the  
same language as the *implementation framework* and we've always known  
that.  A portfile could just as easily be written in a DSL which base/  
implements.  I don't think we should be too constrained in our  
thinking for MacPorts 2.0, since we versioned the crap out of ports'  
individual modules from the beginning precisely in order to enable  
some sharp, incompatible departure(s) in the future.

- Jordan

On Aug 22, 2009, at 2:12 PM, Ryan Schmidt wrote:

> And there are also people who know existing MacPorts syntax well,  
> and do not know Python.
>
>
> I understand Tcl was chosen for a reason, one of them being that it  
> has a nice syntax that doesn't burden you with a lot of quoting and  
> escaping when that isn't necessary in most cases. Having to write
>
> 	name = "foo";
>
> instead of
>
> 	name foo
>
> may not look like a lot of extra characters but it would certainly  
> add up.
>
>
> We have thousands of ports already. It's a little late to change the  
> language now, I think.



More information about the macports-dev mailing list