gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

[Berend de B. <be...@po...>]

Eric Bezault <er...@go...> writes:

>   The comb structure uses indentation, achieved through tab
>   characters (*not* spaces, which are messy, error-prone, and
>   not reader-parameterizable).

they're not parameterizable with every reader, so they look strange in
certain cases. And perhaps they are in ISE's IDE, but haven't detected
that option...

> From what I can see, it seems that the size of tabs used in 
> examples in OOSC2 is 4.

Hmm, I think it's 6 or perhaps just some xx em, not really clear.


> Then I don't see where the problem is. You can convert
> tabs to 3 spaces when you load the Eiffel class into Emacs,
> and convert them back to tabs when you save the file.

Then I don't see where the problem is. You can convert 3 spaces to
tabs when you load the Eiffel class into vim, and convert them back to
tabs when you save the file :-))

The point is that sometimes you have tabs in the file, sometimes
not. Not all editors handle tabs great, so just do away with them.

I agree that your source code works fine with tabs, but most others
don't. Take the SmallEiffel code, take EXML, take whatever source file
you might lay your hands upon.

But whatever we decide, what are our options to guarantee it is done
consistently? At check-in, cron job, code review??

Groetjes,

Berend. (-:

[gobo-eiffel-develop] Re: [gobo-eiffel] external "C" in Gobo

[Christian C. <chc...@cl...>]

Hello,

I just subscribed to this list because I think it is a very good thing
that many project merge and many developers join forces.

And also since a long time I wanted to use gobo in my seif project (see
http://sourceforge.net/projects/seif).

But now I will put this on hold and try to help you first as much as I
can (unfortunately this will perhaps mean not very much since I don't
have a lot of free time).

Regards,
Christian.

Re: [gobo-eiffel-develop] First XACE draft

[Berend de B. <be...@po...>]

Eric Bezault <er...@go...> writes:

> So in my opinion you can continue working on XACE because
> it will be great to have a portable way to write Xace files
> and generate the corresponding compiler-dependent Ace files
> easily on demand (or use the Xace files directly if they
> are natively supported by Visual Eiffel one day).

Yes, generating the correct Ace is very interesting. Currently Ace
doesn't do includes (very limited): VE and SE are more powerful in
this regard.

Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

[Berend de B. <be...@po...>]

Eric Bezault <er...@go...> writes:

> > Raising exceptions is a core feature of eposix:
> 
> Yes, that's what I read in your doc, and to say the least that's
> not what I prefer the most in the design of eposix.

(I'm copying this to eposix mailing list too)

The only other option I see is a global errno variable, like C.

History learns that programmers do not check errors in such
cases. This can lead to security breaches and/or corrupt data.

I also prefer not to think about errors: if there is an error, it is
exceptional, so just quit.

Have you other solutions or suggestions? As exception raising is done
in just one place it's easy to change into an option or something
elese.

Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] First XACE draft

[Andreas L. <no...@sb...>]

On 28 May 2001 19:45:21 +0200, Eric Bezault wrote:

> For the name of your tool, wouldn't it be more consistent
> to call it 'gexace' (or something else but with the prefix
> 'ge')?

Sure, but it's not in GOBO yet. These changes will happen just before
the merger. To do it now, just starts confusion: A tool that is part of
eXML should not start with "ge", a tool that is part of GOBO should.
 
> PS: I look forward to see and try the first prototype
> of your tool on a real example.

Me too.

Btw, I think I will extend condition variables to include values. just
like environment variables. Therefor I was looking for a new command
line syntax and came up with that:

variable-definitions: --define="VAR_NAME[=VALUE]( VAR_NAME[=VALUE])*"

examples: 
--define="FOO=BAR"
--define="FOO=bar ISE VE PLATFORM=linux"

this new form has the advantage that it is get-opt conform. Now this is
not GOBO conform, but I think in this case we should consider changing
the ge-tools to conform to get-opt instead. What do you think?


Andreas

Re: [gobo-eiffel-develop] First XACE draft

[Eric B. <er...@go...>]

Andreas Leitner wrote:
> 
> I have been working on a XACE draft specication and prototype. The
> following is still totally open and subject to change. I just wanted to
> get your feedback (especially from Eric - since I don't want to waste
> furthere time on the project if it is not going to make it into GOBO and
> thus eXML):

If we want Gobo to be some sort of open-source, I don't
think I should be the only one to decide what should
go in Gobo and what shouldn't. If a majority of people
wants something into Gobo, then we should probably listen
to them.

For what XACE is concerned, I didn't look at the proposal
into details yet, but from what I've seen it is much more
flexible and powerful than the pseudo Ace file templates
with 'gepp' that I included in the last release of Gobo.
So in my opinion you can continue working on XACE because
it will be great to have a portable way to write Xace files
and generate the corresponding compiler-dependent Ace files
easily on demand (or use the Xace files directly if they
are natively supported by Visual Eiffel one day).

For the name of your tool, wouldn't it be more consistent
to call it 'gexace' (or something else but with the prefix
'ge')?

PS: I look forward to see and try the first prototype
of your tool on a real example.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] First XACE draft

[Andreas L. <no...@sb...>]

Ooops, wrong list. (;

Andreas

Re: [gobo-eiffel-develop] First XACE draft

[Andreas L. <no...@sb...>]

On 28 May 2001 20:06:42 +0400, Alexander Kogtenkov wrote:
> Andreas Leitner wrote:

> We were planning to introduce the similar XML scheme in VE when "cluster.es"
> was developed. Unfortunately at that time there were no descent XML parser
> and Windows INI files did the job. At  the moment "cluster.es" in its INI format
> is still used, but we would like to switch to XML format sometime.
> 
> It seems that current "cluster.es" works pretty nice for VE, so the future XML
> need to be functionally as rich as "cluster.es" is. It also would be great if
> some common format like the proposed XACE will be used.
> 
> The comparison with "cluster.es" shows that XACE misses the following
> in its current incarnation:
> 1. The possibility to specify the source files
>    a) in several paths
see updated specs
>    b) with different file masks (AFAIK this is only supported by VE - all other
> compilers read only *.e files)
hmmm, dificult. because all other compilers look only for ".e" files.
The most I could do is add an extension, that will only be accepted if
the "--ve" flag is given. not sure if this is a good idea though. 

>    c) depending on some additional settings (like the current OS)
>    d) recursively
> 2. The possibility to specify cluster dependencies taking some settings into
> account (e.g., OS platform again)

Well, that can be handled using condition variables. a native ve
implementation of XACE for example could always define "PLATFORM" to the
current target platform. Or am I missing something. 

> 3. The possibility to specify external dependencies (again taking some settings
> into account).

It's on the todo list and a must have, since I want eXML to work with it
(;

> 1c, 2 and 3 all require some general mechanism to make XACE conditional.
> Using compiler-name variable is OK, but it does not cover all the needs (at least
> not for VE). Some extension mechanism is also required to allow compiler-specific
> options to be specified.

i will look into compiler options later. can you give me examples where
condition variables are not sufficient?

btw, I was thinking about a mechanism to select only subclusters in a
library. alla "GOBO.KERNEL". We could then also allow
"GOBO.KERNEL.SPEC.${EIFFEL_COMPILER}", I think that fits the VE system
more closely, right?

> As to the system settings, usually there are at least two versions of the system -
> debug and finalized. And it would be rather attractive to switch between different
> sets of the settings just by specifying a different command-line parameter or
> by selecting a system type in the GUI environment without the need to modify XACE
> every time. The same applies to libraries (precompiled clusters).

That's where condition variables are totaly sufficient. Just make two
"option" blocks with condtions:

<options condtion="RELEASE_BUILD">
...
</options>
<options condition="DEBUG_BUILD">
...
</options>


> As to two top-level elements ("system" and "library"), there is a possibility that the
> system/library and cluster reside in the same folder, so the description file can list
> properties of both of them. In fact nothing prevents one XACE file to specify several
> related clusters.

Don't understand. Of course you can specify more clusters in once XACE
file.


regards,
Andreas

Re: [gobo-eiffel-develop] First XACE draft

[Andreas L. <no...@sb...>]

On 28 May 2001 20:06:42 +0400, Alexander Kogtenkov wrote:
> Andreas Leitner wrote:

> We were planning to introduce the similar XML scheme in VE when "cluster.es"
> was developed. Unfortunately at that time there were no descent XML parser
> and Windows INI files did the job. At  the moment "cluster.es" in its INI format
> is still used, but we would like to switch to XML format sometime.
> 
> It seems that current "cluster.es" works pretty nice for VE, so the future XML
> need to be functionally as rich as "cluster.es" is. It also would be great if
> some common format like the proposed XACE will be used.

Hehe, if we could come up with a reasonable XACE format and VE would
support it, we could also hack SE to understand XACE. Then 2 or 4
compilers would use XACE nativly - cool (;

I am moving this thread over to: http://www.yahoogroups.com/groups/exml
in order to not "spam" this list with XACE mails. I will send a response
to your message and a refined XACE draft shortly.


regards,
Andreas

Re: [gobo-eiffel-develop] First XACE draft

[Alexander K. <kw...@ah...>]

Andreas Leitner wrote:
...
> It will be a property of XACE that external classes (different from all
> aproaches done till yet) can be nested. So sub-clusters and libraries
> each declare their external dependecies and the resulting build files
> will get this information merged together. This solves the problem of
> combining differen C dependent libraries.
> 
> The xace tool has the following command line usage:
> xace [-DVALUE]* [--se|--ise|--ve|--hact] [options] xace-file
> 
> Where -D defines conditional variables, that serve a similar process
> than they do in gepp. I thought a lot about this. But I think going for
> it is the best way. Here is an example (not yet in Schema) of how such a
> conditional will look like: Only if a variable is defined the cluster
> will be included. the same can be done for options and external clauses
> of course. For every selected compiler a variable with the compiler
> short hand in upper case will be defined automatically.
> 
> --
> <cluster condition="ISE|HACT"> 
>     ...
> </cluster>

We were planning to introduce the similar XML scheme in VE when "cluster.es"
was developed. Unfortunately at that time there were no descent XML parser
and Windows INI files did the job. At  the moment "cluster.es" in its INI format
is still used, but we would like to switch to XML format sometime.

It seems that current "cluster.es" works pretty nice for VE, so the future XML
need to be functionally as rich as "cluster.es" is. It also would be great if
some common format like the proposed XACE will be used.

The comparison with "cluster.es" shows that XACE misses the following
in its current incarnation:
1. The possibility to specify the source files
   a) in several paths
   b) with different file masks (AFAIK this is only supported by VE - all other
compilers read only *.e files)
   c) depending on some additional settings (like the current OS)
   d) recursively
2. The possibility to specify cluster dependencies taking some settings into
account (e.g., OS platform again)
3. The possibility to specify external dependencies (again taking some settings
into account).

1c, 2 and 3 all require some general mechanism to make XACE conditional.
Using compiler-name variable is OK, but it does not cover all the needs (at least
not for VE). Some extension mechanism is also required to allow compiler-specific
options to be specified.

As to the system settings, usually there are at least two versions of the system -
debug and finalized. And it would be rather attractive to switch between different
sets of the settings just by specifying a different command-line parameter or
by selecting a system type in the GUI environment without the need to modify XACE
every time. The same applies to libraries (precompiled clusters).

As to two top-level elements ("system" and "library"), there is a possibility that the
system/library and cluster reside in the same folder, so the description file can list
properties of both of them. In fact nothing prevents one XACE file to specify several
related clusters.

I still do not have the complete picture of what and how can be specified in XACE-like
language, but I do want to see it a cross-platform solution for Eiffel vendors.

Looking forward,
Alexander Kogtenkov
Object Tools, Moscow

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

[Eric B. <er...@go...>]

Berend de Boer wrote:
> 
> Eric Bezault <er...@go...> writes:
> 
> > Consider that we use spaces (wait, I didn't say that I agree
> > to spaces yet! ;-)), then we enter yet another religious war:
> > how many spaces should we put for indentation? With tabs we
> > don't have this problem.
> 
> Emacs gives me 3 spaces, what does OOSC2 say? 

OOSC2, page 894:

  The comb structure uses indentation, achieved through tab
  characters (*not* spaces, which are messy, error-prone, and
  not reader-parameterizable).

>From what I can see, it seems that the size of tabs used in 
examples in OOSC2 is 4.

> > > With Emacs you can tabify sources when you load them and untabify when
> > > saved.
> >
> > What do you mean by "tabify"? Do you mean replace spaces by tabs?
> 
> Yes.

Then I don't see where the problem is. You can convert
tabs to 3 spaces when you load the Eiffel class into Emacs,
and convert them back to tabs when you save the file.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

[Berend de B. <be...@po...>]

Eric Bezault <er...@go...> writes:

> Consider that we use spaces (wait, I didn't say that I agree
> to spaces yet! ;-)), then we enter yet another religious war:
> how many spaces should we put for indentation? With tabs we
> don't have this problem.

Emacs gives me 3 spaces, what does OOSC2 say? I must go away now, I'll
return to this discussion later this evening.

Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

[Berend de B. <be...@po...>]

Eric Bezault <er...@go...> writes:

> > With Emacs you can tabify sources when you load them and untabify when
> > saved.
> 
> What do you mean by "tabify"? Do you mean replace spaces by tabs?

Yes.


> Are you saying that it gives better formatting results in
> example classes but not in library classes? Hmmm...

For typographic reasons: more of example fits on page. 

But I'm not really keen on this one, I just thought it was good to be
100% OOSC2 so people shouldn't have to rewrite, and we can't expect
that if people follow OOSC2. Make it optional at least.


> > Raising exceptions is a core feature of eposix:
> 
> Yes, that's what I read in your doc, and to say the least that's
> not what I prefer the most in the design of eposix.

Interesting discussion, I get back to you this evening.

Groetjes,

Berend. (-:

[gobo-eiffel-develop] First XACE draft

[Andreas L. <no...@sb...>]

I have been working on a XACE draft specication and prototype. The
following is still totally open and subject to change. I just wanted to
get your feedback (especially from Eric - since I don't want to waste
furthere time on the project if it is not going to make it into GOBO and
thus eXML):

Here is the XML Schema:
--
<?xml version="1.0"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

	<xsd:annotation>
		<xsd:documentation xml:lang="en">
			XACE
	        </xsd:documentation>
	</xsd:annotation>

	<!-- the two root level constructs. one for applications, one for
libraries -->
	<xsd:element name="system" type="SystemType"/>
	<xsd:element name="library" type="LibraryType"/>

	<!-- the root element for applications. similar to "system" in ACE
files -->
	<xsd:complexType name="SystemType">
		<xsd:attribute name="name" type="xsd:string" use="required">
		<xsd:sequence>
			<xsd:element name="root" type="RootType" minOccurs="1"
maxOccurs="1"/>
			<xsd:element name="clusters" type="ClustersType" minOccurs="1"
maxOccurs="1"/>
		</xsd:sequence>
	</xsd:complexType>

	<!-- the root element for libraries. -->
	<xsd:complexType name="LibraryType">
		<xsd:attribute name="name" type="xsd:string" use="required"/>
		<xsd:sequence>
			<xsd:element name="clusters" type="ClustersType" minOccurs="1"
maxOccurs="1"/>
		</xsd:sequence>
	</xsd:complexType>

	<!-- element specifieng the root class and creation procedure of a
system -->
	<xsd:complexType name="RootType">
	        <xsd:attribute name="name" type="xsd:string" use="required"/>
	        <xsd:attribute name="creation_procedure" type="xsd:string"
use="required"/>
	</xsd:complexType>

	<!-- sequence of clusters -->
	<xsd:complexType name="ClustersType">
		<xsd:sequence>
			<xsd:element name="cluster" type="ClusterType" minOccurs="0"/>
		</xsd:sequence>
	</xsd:complexType>

	<!-- individual cluster -->
	<xsd:complexType name="ClusterType">
		<xsd:attribute name="name" type="xsd:string" use="required"/>
		<xsd:sequence>
			<xsd:choice>
				<xsd:element name="path" type="xsd:string" minOccurs="1"
maxOccurs="1"/>
				<xsd:element name="library" type="xsd:string" minOccurs="1"
maxOccurs="1"/>
			</xsd:choice>
			<xsd:element name="cluster" type="ClusterType" minOccurs="0"/>
		</xsd:sequence>
	</xsd:complexType>

</xsd:schema>
--

The missing bits (besides meta data such as version, author,
documentation, ...) are external clauses and option clauses.

Here is an example for an XACE file:
--
<?xml version="1.0"?>
<system name="FOO">
	<root class="FOO" creation_procedure="make"/>
	<clusters>
		<cluster name="xace_test">
			<path location="${EXML}/src/xace/test/"/>
			<cluster name="KERNEL">
				<library location="${EXML}/library/kernel.xace"/>
			</cluster>
		</cluster>
	</clusters>
</system>
--



It will be a property of XACE that external classes (different from all
aproaches done till yet) can be nested. So sub-clusters and libraries
each declare their external dependecies and the resulting build files
will get this information merged together. This solves the problem of
combining differen C dependent libraries.

The xace tool has the following command line usage:
xace [-DVALUE]* [--se|--ise|--ve|--hact] [options] xace-file

Where -D defines conditional variables, that serve a similar process
than they do in gepp. I thought a lot about this. But I think going for
it is the best way. Here is an example (not yet in Schema) of how such a
conditional will look like: Only if a variable is defined the cluster
will be included. the same can be done for options and external clauses
of course. For every selected compiler a variable with the compiler
short hand in upper case will be defined automatically.

--
<cluster condition="ISE|HACT"> 
    ...
</cluster>
--

Also the scheme is quite strict now. It never assumes default values.
These can be introduced in a later stage of the project.

The use of the KERNEL library is an interesting application of the
conditional. An application only needs to inlcude this one-liner and the
kernel.xace file that will ship with eXML (together with the xace tool).
The kernel cluster will include conditional clusters so your build files
will only get what they need.

to produce the output for SE for example all that needs to be done in
for the above example is:
xace --se foo.xace

feedback welcome,
Andreas

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

[Eric B. <er...@go...>]

Berend de Boer wrote:
> 
> With Emacs you can tabify sources when you load them and untabify when
> saved.

What do you mean by "tabify"? Do you mean replace spaces by tabs?

> If people cut and paste code from other editors, html browsers,
> whatever you end up with a mix.

Copy/paste is bad practice anyway, you should inherit!
Well OK, it's hard to inherit from an HTML document ;-)

> At least I couldn't find any of your code
> that uses spaces AND tabs for indenting :-)

I'm very consistent when I write code, be it for indentation
or other things. Well, at least I try to be, I'm just a
human being who can make mistakes as anybody else...

> With only spaces:
> 1. your layout is never destroyed
> 2. looks the same on any viewer, even those that do not handle tabs
> properly as the original vi.

3. you cannot set indentations to the size you want.

> > I differ from OOSC2 because all the Eiffel code that I wrote
> > or saw in the projects I work on during the past 10 years or
> > more (even when I was at ISE) put the class name on the same
> > line as the 'class' keyword. That's all.
> 
> You can make this optional. eposix uses the OOSC2 almost
> excusively. For examples (better formatting results) I use your
> approach.

Are you saying that it gives better formatting results in
example classes but not in library classes? Hmmm...

> Raising exceptions is a core feature of eposix:

Yes, that's what I read in your doc, and to say the least that's
not what I prefer the most in the design of eposix.

> if you ask to create a
> directory, it is created or you get an exception. Every failure gives
> you can exception so you don't continue in case of failure.

I personally prefer the style of trying to create a directory
and then check to see whether the creation succeeded or not.
That way the code to handle the problem is near the source of
the problem, whereas with exceptions it is generally far away,
because exceptions have not really been designed in Eiffel
to be part of the flow of control.

> I don't think I use exceptions where it is not clear from the ensure
> clause (which I admit is not always there )-: ).
> 
> Can you agree that when the ensure clause exists, the comment is
> superfluous?

Yes.

>  There should be exceptions when the contract cannot be
> fullfilled, so it should be in the contract.

If the contract (i.e. postcondition) is not fulfilled, then there
is a problem in the implementation of the routine, and it should
be fixed or the contract should be reworked. That's my point of
view at least. I don't think that it is up to the client to handle
problems to fulfill the psotcondition by the implementation of the
suppliers.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

[Eric B. <er...@go...>]

Berend de Boer wrote:
> 
> Therefore, no tabs means exactly the same layout as you see on the
> screen in all occassions.

Consider that we use spaces (wait, I didn't say that I agree
to spaces yet! ;-)), then we enter yet another religious war:
how many spaces should we put for indentation? With tabs we
don't have this problem.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] GOBO and eXML

[Eric B. <er...@go...>]

Berend de Boer wrote:
> 
> Nope, but just a claryfing paragraph in case someone thinks gepp is a
> solution :-)

OK, I'll do that.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

[Berend de B. <be...@po...>]

Eric Bezault <er...@go...> writes:

> Yes, and that exactly why we should use tabs. With spaces
> we cannot set the size of indentations to personal preferences.

With Emacs you can tabify sources when you load them and untabify when
saved. If you can do this with vim you can have tabs the way you want.

So it all boils down to the choice of the proper editor :-))


> > and sources with tabs looks really ugly on my system for example.
> 
> What do you mean by ugly?

If people cut and paste code from other editors, html browsers,
whatever you end up with a mix. And that looks ugly. And emacs is
customizable so you can press tab and have spaces inserted (what many
people use), you can set this with vim too, but few people seem to
customize vim.


> > Your code with tabs looks ugly on any editor with tabs set to
> > something different than 8 spaces ro whatever you have.
> 
> I'm sorry but I don't agree. I set the tab width to different
> sizes and the code is still indented properly and still looks
> fine to me. (BTW, I usually use a size of 4).

I was wrong here, sorry. At least I couldn't find any of your code
that uses spaces AND tabs for indenting :-)


> > Tabs are bad.
> 
> This is your opinion. On the other hand I think that spaces
> are bad.

With only spaces:
1. your layout is never destroyed
2. looks the same on any viewer, even those that do not handle tabs
properly as the original vi.


> > > (Borrow the guidelines from OOSC2 section 26.5 page 891.
> > > Note that contrary to the guidelines in OOSC2, the
> > > recommended layout for Gobo Eiffel classes in to put
> > > the class name on the same line as the 'class' keyword
> > > -- see class BAR above.)
> > 
> > Why differ from OOSC2? I see absolutely no need for this. Just follow
> > OOSC2 and you're almost guaranteed that acceptible libraries for Gobo
> > are formatted correctly.
> 
> I differ from OOSC2 because all the Eiffel code that I wrote
> or saw in the projects I work on during the past 10 years or
> more (even when I was at ISE) put the class name on the same
> line as the 'class' keyword. That's all.

You can make this optional. eposix uses the OOSC2 almost
excusively. For examples (better formatting results) I use your
approach.


> > That's almost any routine in eposix. Hard to specify I think. The
> > ensure clause should be enough to see that an exception
> > follows. Putting it again in the header comment seems superfluous to
> > me.
> 
> I think that it is bad pratice to raise exceptions in Eiffel.
> But at least we should know when such exceptions may occur.
> I don't think this is superfluous.

Raising exceptions is a core feature of eposix: if you ask to create a
directory, it is created or you get an exception. Every failure gives
you can exception so you don't continue in case of failure.

I don't think I use exceptions where it is not clear from the ensure
clause (which I admit is not always there )-: ).

Can you agree that when the ensure clause exists, the comment is
superfluous? There should be exceptions when the contract cannot be
fullfilled, so it should be in the contract.

If it is not in the contract, perhaps you shouldn't generate
exceptions (so a comment is an indication that something is wrong).

Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

[Berend de B. <be...@po...>]

Eric Bezault <er...@go...> writes:

> An editor which saves on disk something different from
> what I typed, who's the problem so?

It does not. You can set it all. And it comes up with Emacs because it
is so customizable so people change it. vim is seldom customized if I
look around at vim users I know.

1. Not all editors can handle tabs properly.
2. Not all display engines (html for example) allow tab width to be
settable.

Therefore, no tabs means exactly the same layout as you see on the
screen in all occassions.

Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] GOBO and eXML

[Berend de B. <be...@po...>]

Eric Bezault <er...@go...> writes:

> Exactly. And what is wrong? Just the fact that Eiffel compilers
> are not compatible, right?

Indeed, too sad.


> I don't think we disagree here.

Nope, but just a claryfing paragraph in case someone thinks gepp is a
solution :-)

Groetjes,

Berend. (-:

Re: [gobo-eiffel-develop] GOBO and eXML

[Eric B. <er...@go...>]

Berend de Boer wrote:
> 
> For eposix I'm working on a Makefile generator that will make the
> libeposix.lib on Windows. Can be used by expat as well to generate the
> correct Windows Makefile.

Looking forward to seeing this Makefile generator.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] GOBO and eXML

[Eric B. <er...@go...>]

Berend de Boer wrote:
> 
> Eric Bezault <er...@go...> writes:
> 
> > I would suggest that you put all your external routines in
> > a class *_EXTERNALS along with routines without POINTERs
> > as arguments or results, and that you put this class in
> > clusters spec/[ise|se|ve|hact] (you can possibly use 'gepp').
> 
> I think #ifdefs are an absolutely bad way to manage code. Perhaps in a
> few low level classes I can live with them, but generally they
> generate a mess of used on a larger scale. So lets avoid them at all
> costs.
> 
> Perhaps put this in the guidelines as well:
> 1. gepp only to be used for ise/se/ve/hact distinctions.

I agree, and that's what I suggested above, nothing else.
Perhaps I was not clear enough.

> 2. deferred classes are a much better choice. gepp is completely
>    orthogonal to oo programming in almost any case. If you use it,
>    there is something wrong.

Exactly. And what is wrong? Just the fact that Eiffel compilers
are not compatible, right?

I don't think we disagree here.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

[Eric B. <er...@go...>]

Berend de Boer wrote:
> 
> Please no editor war,

If we cannot fight on that, what should we do?
Fight on semicolons ;-)

> Just not true, please read the url.

I read it, but since it is inexact wrt Vim I didn't
take it for granted.

> Because the problem is not Eamcs, but tabs and of course this is all
> settable, please read the url.

An editor which saves on disk something different from
what I typed, who's the problem so?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

[Eric B. <er...@go...>]

Berend de Boer wrote:
> 
> What about the create construct?

It is not supported by Visual Eiffel yet.

> Forbid tabs. Everybody uses a different tab width 

Yes, and that exactly why we should use tabs. With spaces
we cannot set the size of indentations to personal preferences.

> and sources with tabs looks really ugly on my system for example.

What do you mean by ugly?

> Your code with tabs looks ugly on any editor with tabs set to
> something different than 8 spaces ro whatever you have.

I'm sorry but I don't agree. I set the tab width to different
sizes and the code is still indented properly and still looks
fine to me. (BTW, I usually use a size of 4).

> Tabs are bad.

This is your opinion. On the other hand I think that spaces
are bad.

> > (Borrow the guidelines from OOSC2 section 26.5 page 891.
> > Note that contrary to the guidelines in OOSC2, the
> > recommended layout for Gobo Eiffel classes in to put
> > the class name on the same line as the 'class' keyword
> > -- see class BAR above.)
> 
> Why differ from OOSC2? I see absolutely no need for this. Just follow
> OOSC2 and you're almost guaranteed that acceptible libraries for Gobo
> are formatted correctly.

I differ from OOSC2 because all the Eiffel code that I wrote
or saw in the projects I work on during the past 10 years or
more (even when I was at ISE) put the class name on the same
line as the 'class' keyword. That's all.

> That's almost any routine in eposix. Hard to specify I think. The
> ensure clause should be enough to see that an exception
> follows. Putting it again in the header comment seems superfluous to
> me.

I think that it is bad pratice to raise exceptions in Eiffel.
But at least we should know when such exceptions may occur.
I don't think this is superfluous.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] GOBO and eXML

[Berend de B. <be...@po...>]

Eric Bezault <er...@go...> writes:

> I would suggest that you put all your external routines in
> a class *_EXTERNALS along with routines without POINTERs
> as arguments or results, and that you put this class in
> clusters spec/[ise|se|ve|hact] (you can possibly use 'gepp').

I think #ifdefs are an absolutely bad way to manage code. Perhaps in a
few low level classes I can live with them, but generally they
generate a mess of used on a larger scale. So lets avoid them at all
costs. 

Perhaps put this in the guidelines as well:
1. gepp only to be used for ise/se/ve/hact distinctions.
2. deferred classes are a much better choice. gepp is completely
   orthogonal to oo programming in almost any case. If you use it,
   there is something wrong.

For example, if a new Eiffel compiler pops up (Eiffel .NET comes to
mind), you have to scrawl all over your code to fix the #ifdefs and
not forget anything.

Deferred classes with a proper implementation work just as good and
give you a nice warning if you forgot to implement a method.

Groetjes,

Berend. (-: