[gentoo-portage-dev] Portage-NG implementation language(s)

[gentoo-portage-dev] Portage-NG implementation language(s)

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

Hi,

Seeing this "language war" on -dev I think I should say again that the
component model should make us free from language restrictions. There is
no sense in saying "we should use language XXX for portage-ng" as the
goal should be that each component can be implemented in the best
fitting language. So it should be possible to have the dependency
resolver in prolog, the ebuild parser in perl, the frontend in python,
the storage backend in C and so on. Instead of arguing about the "best"
language for implementation we should discuss about the language for the
_interface_ for the component interaction.
Once we have decided on that we can start creating the global
architecture that describes which components interact with each other,
which components are mandatory or optional and so on. Later in that
process we can specify the first function signatures and start
implementing the individual components. Then and not earlier we have to
choose the implementation language.
I hope we can stop the "let's use XXX" discussion now.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-portage-dev] Portage-NG implementation language(s)

[Jason Stubbs]

On Saturday 06 December 2003 02:09, Marius Mauch wrote:
> Seeing this "language war" on -dev I think I should say again that the
> component model should make us free from language restrictions. There is
> no sense in saying "we should use language XXX for portage-ng" as the
> goal should be that each component can be implemented in the best
> fitting language. So it should be possible to have the dependency
> resolver in prolog, the ebuild parser in perl, the frontend in python,
> the storage backend in C and so on. 

I believe this is already part of the requirements.

> Instead of arguing about the "best" 
> language for implementation we should discuss about the language for the
> _interface_ for the component interaction.
> Once we have decided on that we can start creating the global
> architecture that describes which components interact with each other,
> which components are mandatory or optional and so on.

I think the point is that even designing the global architecture should come 
before deciding on a language for the component interaction interface.

> Later in that 
> process we can specify the first function signatures and start
> implementing the individual components. Then and not earlier we have to
> choose the implementation language.

This is correct. The implementation language for a particular component will 
be chosen once the framework is decided and it is time to create said 
particular component within that framework.

Regards,
Jason Stubbs

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Portage-NG implementation language(s)

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]

On 12/06/03  Jason Stubbs wrote:

> On Saturday 06 December 2003 02:09, Marius Mauch wrote:
> > Seeing this "language war" on -dev I think I should say again that
> > the component model should make us free from language restrictions.
> > There is no sense in saying "we should use language XXX for
> > portage-ng" as the goal should be that each component can be
> > implemented in the best fitting language. So it should be possible
> > to have the dependency resolver in prolog, the ebuild parser in
> > perl, the frontend in python, the storage backend in C and so on. 
> 
> I believe this is already part of the requirements.

Yes, I just wanted to say it again as I saw the thread on -dev.

> I think the point is that even designing the global architecture
> should come before deciding on a language for the component
> interaction interface.

While I agree in general I think it's much easier to discuss the
architecture when we can use a uniform syntax. This doesn't have to be a
real language, Pseudo Code would work too but we would have to define
the syntax first, so we can choose the interface language right then
(and the number of choices isn't that large).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: [gentoo-portage-dev] Portage-NG implementation language(s)

[jasonbstubbs]

On 12/06/03 Marius Mauch wrote:
> On 12/06/03  Jason Stubbs wrote:
> > I think the point is that even designing the global architecture 
> > should come before deciding on a language for the component 
> > interaction interface.
> 
> While I agree in general I think it's much easier to discuss the
> architecture when we can use a uniform syntax. This doesn't
> have to be a real language, Pseudo Code would work too but 
> we would have to define the syntax first, so we can choose the 
> interface language right then (and the number of choices isn't 
> that large).

Okay, so you're talking IDL or OCL or such. Not much point in
reinventing the wheel for that one. That is something that would need to
be decided before setting out a design (although it would probably be
decided per design by the designer). However, that's still a ways off -
we still need to figure out exactly what needs to be designed first. You
sound like you have a fair bit of development experience so you must
know the headache that a change in requirements mid-project brings! ;-)

Regards,
Jason Stubbs

P.S. I hope this wraps correctly. Using M$ at the moment. :-(


--
gentoo-portage-dev@gentoo.org mailing list