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