Menu
▾
▴
gobo-eiffel-develop
|
From: Berend de B. <be...@po...> - 2001-05-28 10:56:50
|
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. (-: |
|
From: Eric B. <er...@go...> - 2001-05-28 12:05:19
|
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 |
|
From: Berend de B. <be...@po...> - 2001-05-28 15:09:43
|
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. (-: |
|
From: Eric B. <er...@go...> - 2001-05-28 12:05:25
|
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 |
|
From: Berend de B. <be...@po...> - 2001-05-28 15:09:43
|
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. (-: |
|
From: Berend de B. <be...@po...> - 2001-05-28 19:09:57
|
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. (-: |
|
From: Eric B. <er...@go...> - 2001-05-28 15:32:03
|
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 |
|
From: Berend de B. <be...@po...> - 2001-05-28 19:40:00
|
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. (-: |
|
From: Eric B. <er...@go...> - 2001-05-28 22:18:56
|
Berend de Boer wrote: > > The only other option I see is a global errno variable, like C. Global? Or just an attribute of class PX_DIRECTORY (or whatever its name is in epoix) in the example of directory creation? > History learns that programmers do not check errors in such > cases. This can lead to security breaches and/or corrupt data. Crashing the program may lead to corrupted data as well. > I also prefer not to think about errors: if there is an error, it is > exceptional, so just quit. If I cannot create a directory, it's not exceptional. I just ask the user to enter an another directory name in the popup window. You prefer not to think about errors, but for people who do care about writing robust code having to deal with exceptions makes life much more complicated than testing for errors. > 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. Could the use of exceptions or error variables be parameterized, for example use different creation routines if I want operations applied to this object to raise exceptions or set a boolean attribute when an error occurs? Well, an other solution could be to have two sets of routines, one with exceptions and one with an error status boolean to be set on error. This latter solution has the advantage of possibly providing slightly different postconditions for the two sets of routines. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Berend de B. <be...@po...> - 2001-05-29 06:10:03
|
Eric Bezault <er...@go...> writes: >> The only other option I see is a global errno variable, like C. > Global? Or just an attribute of class PX_DIRECTORY (or > whatever its name is in epoix) in the example of > directory creation? One error variable per object or a more global one, so you only have the last error? > If I cannot create a directory, it's not exceptional. > I just ask the user to enter an another directory > name in the popup window. Most of the code I write is middleware and there's usually no user looking at the server screen :-) Groetjes, Berend. (-: |
|
From: Eric B. <er...@go...> - 2001-05-28 22:18:57
|
Berend de Boer wrote: > > 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 :-)) I don't understand: on one hand you say that we should follow OOSC2 guidelines and not reinvent the wheel, and on the other hand you reject it when it does not fit your liking. > 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, Written using Emacs... > take EXML, Written using Emacs... > take whatever source file you might lay your hands upon. I don't know about this one ;-) I know, it is not an editor problem, unless proven otherwise ;-) > But whatever we decide, what are our options to guarantee it is done > consistently? That's what guidelines are for, and that's why I explicitly put this rule in the first draft of the guidelines. I was hoping that people would follow the guidelines without me having to play the cop. What are the options to guarantee that people will use spaces consistently if we decide to go with spaces? What are the options to guarantee that all the other rules specified in the guidelines are followed consistently? To be honest I would prefer people to care by themselves about writing consistent code (that's why I started to write some guidelines) rather than to waste my time writing tools and scripts to check that nobody violates the rules. But if you think that such tools and scripts should be written because we cannot trust Eiffel programmers, well... sadly let's do it. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Berend de B. <be...@po...> - 2001-05-29 06:02:06
|
Eric Bezault <er...@go...> writes:
> I know, it is not an editor problem, unless proven otherwise ;-)
It is the mix of tabs and spaces that causes problems. Just add this
line
set tabstop=2
in your .vimrc and browse a few files, not of your own, and you see
the problems (take lib_std/collection3.e for example).
> > But whatever we decide, what are our options to guarantee it is done
> > consistently?
>
> That's what guidelines are for, and that's why I explicitly
> put this rule in the first draft of the guidelines.
Not enough. People are not good at tiny details as programming prooves
again and again.
So at least there should be support for commonly used editors that
automagically make the code correct. As Emacs is infinitely extensible
it appears to be the candidate for this job...
If I find time today (might well be saturday), I'll experiment with
the various Emacs Eiffel hooks and the eiffel-mode to see what can be
done. And perhaps a sed script to convert existing code to tab format.
Groetjes,
Berend. (-:
|
|
From: Eric B. <er...@go...> - 2001-05-28 22:19:09
|
Berend de Boer wrote: > > 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. OK, let's make our life easier and follow OOSC2 instead of reinventing the wheel. I think that in that case if there is something optional, it should be the form not present in OOSC2 guidelines. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Christian C. <chc...@cl...> - 2001-05-29 04:45:58
|
Eric Bezault wrote : > > Berend de Boer wrote: > > > > 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. > > Could the use of exceptions or error variables be parameterized, > for example use different creation routines if I want operations > applied to this object to raise exceptions or set a boolean > attribute when an error occurs? Well, an other solution could > be to have two sets of routines, one with exceptions and one > with an error status boolean to be set on error. This latter > solution has the advantage of possibly providing slightly > different postconditions for the two sets of routines. I would rather have a base class using error variables and a derived class (inheriting the base class) with exceptions. Or something like this. I think it's far better than two set of routines (doing essentialy the same thing) in the same class. Regards, Christian. |
|
From: Eric B. <er...@go...> - 2001-05-29 08:29:08
|
Berend de Boer wrote: > > It is the mix of tabs and spaces that causes problems. Just add this > line > > set tabstop=2 > > in your .vimrc and browse a few files, not of your own, and you see > the problems (take lib_std/collection3.e for example). Yes, I'm well aware of this problem. That's why I suggested in the guideline to use only tabs. > And perhaps a sed script to convert existing code to tab format. I already suggested that at the beginning of the discussion but apparently to didn't read it. I even suggested to write this tool in Eiffel because some 'sed' may not be installed on all platforms: ! OK, I'll try to put together such little scripts ! and let you know when they are ready. I'll try to ! make them configurable so that we can specify the ! size of the tabs, and have two modes to convert ! tabs back and forth. Hmmm, we need something ! OS-independent to write these scripts. I think the ! best choice for platform independent language in ! the context of the development of Gobo Eiffel ! package is ... Eiffel. What do you think? If you want to write such tool, please do. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2001-05-29 08:29:10
|
Christian Couder wrote:
>
> I would rather have a base class using error variables and a derived
> class (inheriting the base class) with exceptions.
> Or something like this. I think it's far better than two set of routines
> (doing essentialy the same thing) in the same class.
Why not. What do you think about that Berend?
On the other hand with the first solution that I suggested
(deciding at creation time of the object if it will raise
exceptions or if it only uses an error variable) we can have
only one set of routines which call a `set_last_error'
routine when an error occur:
set_last_error (...) is
-- ...
do
last_error := ....
if exeptions_enabled then
raise (...)
end
end
--
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com
|
|
From: Eric B. <er...@go...> - 2001-05-29 08:29:11
|
Berend de Boer wrote: > > One error variable per object or a more global one, so you only have > the last error? I would rather say one error variable per object. The last error per object seems enough. > Most of the code I write is middleware and there's usually no user > looking at the server screen :-) That's the most difficult part when rewriting _reusable_ libraries: it should not only work for the author of the library but should also address the needs of the other potential users. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2001-05-29 21:40:19
|
Christian Couder wrote: > > I would rather have a base class using error variables and a derived > class (inheriting the base class) with exceptions. The more I think about it, the more I like this solution. In the parent class the postconditions do not state that the operation succeeded and the error variable is set on error, and in the heir class the postcondtions are strengthened to state that the operation succeeded and an exception is raised on error. Berend, what's your opinion about this design? At least it has the advantage of providing both programming styles to the clients of this library. I didn't look at the implementation of your library so I don't know whether this may cause implementation problems or involve too much work for you to modify your classes. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Berend de B. <be...@po...> - 2001-05-31 17:54:53
|
Eric Bezault <er...@go...> writes: > Berend, what's your opinion about this design? At least > it has the advantage of providing both programming > styles to the clients of this library. I didn't look > at the implementation of your library so I don't know > whether this may cause implementation problems or > involve too much work for you to modify your classes. The latter. I currently cannot afford the time to do this. I'll start making the latest errno available per object and not crash on failure, but rewriting everything is too much. I'm thinking about this solution and when I like it I can use it for the socket/ftp/http stuff I'm working on, but it looks to me like lots of work with not so much real value, but I'll ponder over it a while and do some experiments. Also: you have to invent another prefix to make the distinction clear. Groetjes, Berend. (-: |
|
From: Christian C. <chc...@cl...> - 2001-05-30 05:36:01
|
Eric Bezault wrote: > > Christian Couder wrote: > > > > I would rather have a base class using error variables and a derived > > class (inheriting the base class) with exceptions. > > Or something like this. I think it's far better than two set of routines > > (doing essentialy the same thing) in the same class. > > Why not. What do you think about that Berend? > > On the other hand with the first solution that I suggested > (deciding at creation time of the object if it will raise > exceptions or if it only uses an error variable) we can have > only one set of routines which call a `set_last_error' > routine when an error occur: > > set_last_error (...) is > -- ... > do > last_error := .... > if exeptions_enabled then > raise (...) > end > end Yes, but every object will have an exeptions_enabled attribute, this means the size of each object will increase. Perhaps there should be a global error manager object (a once object) using an error handler, like this: class ERROR_MANAGER feature current_error_handler: ERROR_HANDLER; default_error_handler: ERROR_HANDLER; creation make feature make(error_handler: ERROR_HANDLER) is do default_error_handler := error_handler current_error_handler := default_error_handler end set_new_error_handler(error_handler: ERROR_HANDLER) is do current_error_handler := error_handler end reset_error_handler is do current_error_handler := default_error_handler end set_last_error(error: INTEGER; error_creator: ERROR_CREATOR) is do ... current_error_handler.handle_error(error, error_creator) end end The error handler objects could all inherit from the same base class and do what should be done in case of an error (nothing or raise an exeption or send a mail or trace the error, ...) Also the error manager could have a dictionary to save the last error for each object that had an error. It would save space in each object since hopefully very few objects will have errors. Regards, Christian. |
|
From: Eric B. <er...@go...> - 2001-05-27 19:14:25
|
Andreas Leitner wrote: > > I will remove the make_pointer_ features from C_STRING_HELPER, rename > make_ to new_ and unify the class using GEPP as you suggested. I think > the class needs a better name. Do you have an idea? Not yet. I have to think about it. Finding good names requires as much effort (or even more) than actually writing the class library itself... > When I am ready, I > can post it here, so you can include it into GOBO as soon as UCSTRING > gets merged into GOBO. Is that ok with you? OK. Or you can send it directly to me if you don't want to bother others in this mailing list with class texts. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2001-05-27 22:22:21
|
Andreas Leitner wrote: > > The same argument can be made for spaces only. Except that only people using Emacs put spaces instead of tabs. So I think this is a problem with people using Emacs, not people using the others text editors. > What are you using? CodeWright and Vim. > That was actually a point I forgot to mention. We _should_ come up with > a standard (and be it spaces only) and we _should_ come up with tools > (as part of GOBO) that automate as much of the bookkeeping work as > possible. Indentation can be done completly automatic and we should > strive for this goal. We may not archive this in the short term, but we > can start with little scripts as yours. OK, I'll try to put together such little scripts and let you know when they are ready. I'll try to make them configurable so that we can specify the size of the tabs, and have two modes to convert tabs back and forth. Hmmm, we need something OS-independent to write these scripts. I think the best choice for platform independent language in the context of the development of Gobo Eiffel package is ... Eiffel. What do you think? > In the long term, I think your gelint effort could be used as a basis > for a GOBO style pretty printer. Yes, a pretty-printer can be written re-using the same code as 'gelint'. The only problem with pretty-printers is that they usually do not handle free comments properly in a nice way. > Then before a checkin I run the pretty > printer and before opening a file, I run the Emacs indentation command > to get my preferred indentation. I think we will already be able to do that with the little scripts described above. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Andreas L. <no...@sb...> - 2001-05-27 22:31:34
|
On 28 May 2001 00:19:39 +0200, Eric Bezault wrote: > Andreas Leitner wrote: > OK, I'll try to put together such little scripts > and let you know when they are ready. I'll try to > make them configurable so that we can specify the > size of the tabs, and have two modes to convert > tabs back and forth. Hmmm, we need something > OS-independent to write these scripts. I think the > best choice for platform independent language in > the context of the development of Gobo Eiffel > package is ... Eiffel. What do you think? Good choice. Btw, whats that Eiffel thing ppl. here on the list keep talking about? > > > In the long term, I think your gelint effort could be used as a basis > > for a GOBO style pretty printer. > > Yes, a pretty-printer can be written re-using the > same code as 'gelint'. The only problem with > pretty-printers is that they usually do not handle > free comments properly in a nice way. Maybe if we restrict ourselfe to write free comments in a certain fashion this problem can be overcome. Dunno, have not thought about this yet (; > > Then before a checkin I run the pretty > > printer and before opening a file, I run the Emacs indentation command > > to get my preferred indentation. > > I think we will already be able to do that with the > little scripts described above. Great. Meanwhile I will look into XML Schemas and try to cut out a first draft of XACE (I have several new ideas since the last version :). Maybe I can get a minimal (but functional enough - for our purposes) done in a reasonable time. Btw, it looks like there is a new SE beta out with preliminart ACE support. They do follow the ISE conventions quite closely, but for now they do not support the external clause. Ad graphviz: I tried several versions including rolling my own from source they always run endlessly and consume more and more RAM every second. What version are you using? regards, Andreas |
|
From: Eric B. <er...@go...> - 2001-05-27 23:27:55
|
Andreas Leitner wrote: > > Good choice. Btw, whats that Eiffel thing ppl. here on the list keep > talking about? I think it's a iron tower in Paris :-) > Maybe if we restrict ourselfe to write free comments in a certain > fashion this problem can be overcome. So, it's not really free comments anymore ;-) > Btw, it looks like there is a new SE beta out with preliminart ACE > support. Yes, I saw your message in comp.lang.eiffel today. > They do follow the ISE conventions quite closely, Sounds great. > but for now they do not support the external clause. Perhaps in future releases... > Ad graphviz: I tried several versions including rolling my own from > source they always run endlessly and consume more and more RAM every > second. What version are you using? I'm using version 1.7 under Windows. I know that Franck Arnaud uses it under Linux, so it should work. I'll ask him what version he is using on Linux. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2001-05-28 09:34:47
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X