headers
Peter Gummer | 1 Feb 2009 01:36
Picon

Re: Getting rid of "Void"?

Thomas Beale wrote:
> Re: the Hoare paper, it only applies to generic computing structures, it 
> does not apply conveniently to business objects, which are also 
> expressed in the same computing languages. This is because business 
> objects have many 'optional' elements, and to make models of them in a 
> Void-less way would create a horrible and unusable type model. I agree 
> that the base libraries and other similar computing libraries should be 
> Void-safe, but large application systems will have many business 
> objects, for which there is no hope of being Void-safe. Realistic 
> systems will have to allow both kinds of libraries.
>   

I think you're confusing the term "void-safe" with "void-less", Thomas. 
A system may be void-safe while still using "void" extensively.

On the topic of "void-less-ness", I'm not convinced that base libraries 
use void that much less frequently than business applications. Generic 
computing structures use void frequently; think of linked lists, for 
example.

Nonetheless, I don't think the original proposal was to make systems 
"void-less" anyway. I thought that the original proposal was to get rid 
of the "void" keyword. I saw no proposal to change the semantics of 
attachment and detachment.

I would be happy with using the proposed new "attached" and "detach" 
syntax. My only question was why was this change being proposed? I'm 
still not clear about the rationale behind it.

- Peter Gummer
(Continue reading)

Permalink | Reply | 3 comments |
headers
Thomas Beale | 1 Feb 2009 01:59

Re: Getting rid of "Void"?

Peter Gummer wrote:
 >
 > Thomas Beale wrote:
 > > Re: the Hoare paper, it only applies to generic computing 
structures, it
 > > does not apply conveniently to business objects, which are also
 > > expressed in the same computing languages. This is because business
 > > objects have many 'optional' elements, and to make models of them in a
 > > Void-less way would create a horrible and unusable type model. I agree
 > > that the base libraries and other similar computing libraries should be
 > > Void-safe, but large application systems will have many business
 > > objects, for which there is no hope of being Void-safe. Realistic
 > > systems will have to allow both kinds of libraries.
 > >
 >
 > I think you're confusing the term "void-safe" with "void-less", Thomas.
 > A system may be void-safe while still using "void" extensively.
 >

I did mean to say void-safe. The problem remains: class models, seen as 
classificatory ontologies of real world concepts (i.e. what we usually 
call business objects) can't easily be made void-safe because the 
classifications (things such as PERSON, ACCOUNT) are generally quite 
broad, and encompass many variations where certain attributes may be 
void, more or less arbitrarily.

- thomas beale

------------------------------------
(Continue reading)

Permalink | Reply | 2 comments |
headers
Peter Gummer | 1 Feb 2009 02:05
Picon

Re: Getting rid of "Void"?

Thomas Beale wrote:
> I did mean to say void-safe. The problem remains: class models, seen as 
> classificatory ontologies of real world concepts (i.e. what we usually 
> call business objects) can't easily be made void-safe because the 
> classifications (things such as PERSON, ACCOUNT) are generally quite 
> broad, and encompass many variations where certain attributes may be 
> void, more or less arbitrarily.
>   

This doesn't prevent void-safety. Wherever there is the possibility of 
'x' being void, you simply protect access to it with "if x /= Void" or 
"require x /= Void" or "check x /= Void", or with an object test.

- Peter Gummer

------------------------------------
Permalink | Reply | 1 comment |
headers
Thomas Beale | 1 Feb 2009 13:37

Re: Getting rid of "Void"?

Peter Gummer wrote:
 >
 > Thomas Beale wrote:
 > > I did mean to say void-safe. The problem remains: class models, seen as
 > > classificatory ontologies of real world concepts (i.e. what we usually
 > > call business objects) can't easily be made void-safe because the
 > > classifications (things such as PERSON, ACCOUNT) are generally quite
 > > broad, and encompass many variations where certain attributes may be
 > > void, more or less arbitrarily.
 > >
 >
 > This doesn't prevent void-safety. Wherever there is the possibility of
 > 'x' being void, you simply protect access to it with "if x /= Void" or
 > "require x /= Void" or "check x /= Void", or with an object test.
 >

I think my main point here is that half the code in a typical business 
information system should be compiled with void-safe types as the 
default, while the other half should not. Currently, as far as I can 
see, we would have to go and change all the type declarations in 
business classes from T to ?T, since void-safe compiling applies 
globally, not on a per-cluster or subsystem basis. Or else we just keep 
void-safe checking turned off, in which case the advantages in the base 
libraries are not used.

- thomas

------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hubert Cater | 1 Feb 2009 15:33

C Run-Time Error R6002

I'm having a bit of trouble with the latest Windows SDK 6.1 C-compiler.

Initially my executables run fine but once they are wrapped with a DRM 
called eLicense it seems to expose a C Run-Time Error R6002 which 
complains that floating-point support is not loaded.

Is there any way to force the C-compiler to load the floating-point 
support library even if it may not initially use it until it is wrapped 
with the DRM?

Any help would be much appreciated.  So far I've only been able to find 
this information page from Microsoft wrt the error but I am really not 
sure how to proceed to fix the problem on my end, thanks.

http://msdn.microsoft.com/en-us/library/k1x26e0x(VS.71).aspx

Hubert

--

-- 
Fury Software
http://www.furysoftware.com

Battlefront.com
http://www.battlefront.com

------------------------------------
Permalink | Reply | 16 comments |
headers
Martin Piskernig | 1 Feb 2009 16:11
Picon
Picon
Favicon

Re: Help with wrapper for C++

On Samstag, 31. Januar 2009, Jimmy J. Johnson wrote:
> int sqlite3_open(
>   const char *filename,   /* Database filename (UTF-8) */
>   sqlite3 **ppDb          /* OUT: SQLite db handle */
> );

It is not _that_ easy to give a simple wrapper for this function. You 
can use STRING_8 for C strings (and convert to a char* in the external 
routine with STRING_8.to_c) but you will have to wrap the "sqlite3" 
struct in Eiffel if you need access to its members. If you only need it 
as a pointer then use POINTER. From the sqlite3 it seems that you don't 
need access to the sqlite3 struct members but use it as opaque type.

An untested very simple wrapper may look like:

class SQLITE
...
feature

sqlite3:POINTER

sqlite3_open(filename:ANY;ppdb:POINTER):INTEGER is
	external "C++ inline use <sqlite3.h>"
	alias "return sqlite3_open((const char*)$filename,&((sqlite3*)$ppdb));"
	end
...
end

Call it like:
sqlite3_open("mydb".to_c,sqlite3);
(Continue reading)

Permalink | Reply | 5 comments |
headers
David Jenkins | 1 Feb 2009 23:09
Picon

Save assignment attempt!


  I rise in defense of assignment attempt, gone but not forgotten, once
favored but now a red-headed stepchild. The more I think about object
test and void safety, the more I prefer assignment attempt. To
demonstrate what I mean, here are few lines from an application I wrote
pre-ECMA Eiffel that deals with aircraft components:

db_row: DB_TUPLE -- from the EiffelStore library. An instance of
DB_TUPLE is a generic  row returned from a database query

install_date: DATE_TIME -- the date on which a component was installed
on an aircraft.

...

install_date ?= db_row.item(5) -- the install date is in column 5 of the
database table

check

   install_date_attached: install_date /= Void – the installation
date must be some value

end

This is from the creation procedure of the INSTALLATION class that
models an installation/removal pair of an aircraft component, at the
point where data read from a database is being assigned to attributes of
the object. As each INSTALLATION object is created and initialized, it's
added to a container object. The application refers to the INSTALLATION
(Continue reading)

Permalink | Reply | 21 comments |
headers
Ian Joyner | 2 Feb 2009 00:14
Picon
Favicon

Re: Getting rid of "Void"?

Hmmm, I think any 'create' instruction is a non-automatic create. Both  
that and detach would be exceptions to solve some problem which I  
don't like. But programmers do understand scope and how entities will  
come into and go out of being as blocks are entered and exited. That  
is where the concept of objects came from in the first place when the  
Simula people realized they could detach an activation record (stack  
frame) from the stack.

I think there is a lot to think about and experiment with, but I don't  
have time to do it to simplify the program model and hence language.

Ian

On 31/01/2009, at 11:42 PM, David Broadfoot wrote:
> > > I don't think there is any confusion if you do it like this...
> > >
> > > For this code:
> > > t: T
> > > x: T1	 -- where T1 is a subtype of T (or just T)
> > >
> > > loop
> > > ...
> > > t := x
> > > ...
> > > end
> > >
> > > ... I suggest that x should be created the first time it is used,
> > > and the
> > > same 'x' is reassigned to 't' on every loop iteration. That is
> > > consistent
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Joyner | 2 Feb 2009 00:29
Picon
Favicon

Re: Save assignment attempt!

I made a proposal in an Objective-C forum recently, where one  
correspondent saw compiler checking as "bondage and discipline".  
Anyway, I attempted to explain why it is better to make explicit  
exceptions that the programmer controls, rather than having a blanket  
anything-goes policy:

http://web.me.com/ianjoyner/Ian_Joyner/Typing.html

Following on from that, I can see why Void is difficult to fit in the  
type system (as Bertrand, I think recently posted). Void is of type  
NONE, which inherits from all classes, Thus any call on a Void  
reference should be valid (according to the type system and as  
implemented in dynamic languages such as Smalltalk and Objective-C).  
However, calls on a void reference are almost always an error.

In summary, I think the desire is to leave some things to runtime but  
this should be an explicit decision, not implicit as in most of  
today's dynamic languages.

Ian

On 02/02/2009, at 9:09 AM, David Jenkins wrote:

>
> I rise in defense of assignment attempt, gone but not forgotten, once
> favored but now a red-headed stepchild. The more I think about object
> test and void safety, the more I prefer assignment attempt. To
> demonstrate what I mean, here are few lines from an application I  
> wrote
> pre-ECMA Eiffel that deals with aircraft components:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gummer | 2 Feb 2009 00:48
Picon

Re: Save assignment attempt!

David Jenkins wrote:
> The current ECMA-inspired object test syntax does away with assignment
> attempt and requires me to make two changes. 'install_date' is declared
> as an attached type
>
>    install_date: !DATE_TIME -- The '!' is superfluous; types are attached
> by default
>
> and its initialization is guarded by an object test:
>
>    if {t5:DATE_TIME}db_row.item (5) then
>      install_date := t5
>    end
>   

You've omitted the "check" statement, David. For the same outcome as 
before, do this:

   if {t5: DATE_TIME} db_row.item (5) then
     install_date := t5
   else
     check false end
   end

But that's very awkward. A better way to write it is this:

   check {t5: DATE_TIME} db_row.item (5) end
   install_date := t5

Two lines. It's exactly the same number of lines as your old assignment attempt version.
(Continue reading)

Permalink | Reply | 10 comments |

Gmane