«

There is one really bad thing with object oriented languages:

My view of objects and your view of objects may differ a lot.
That's the beauty of plain C API:s. When I get the API from a
supplier I wrap it within my objects seen from my point of view.

Take threads for instance. I don't like the Java
overload-thread::run()-style of threads. What does a typical
thread class look like from your point of view? (or anyone else
reading this)

Best regards
Daniel Marcus


PS. I like your idea, but I may or may not like your view of
objects.



Michael Groys wrote:
> Hello all,
> I'm looking for collaborators to develop new object oriented operating
> system.
> As most of the software development had moved to the OO languages so
> the OS must move towards OO OS.
> I think that it will be very interesting project with big potential.
> So everybody is invited.
> More information you can find at,
> http://www.yaooos.org
> Michael

While it was 1/2/04 2:26 pm throughout the UK, Michael Groys sprinkled
little black dots on a white screen, and they fell thus:
> Hello all,
> I'm looking for collaborators to develop new object oriented operating
> system.
> As most of the software development had moved to the OO languages so
> the OS must move towards OO OS.
<snip>

I suppose that would be a nice concept. All the better if it can be
made compatible with C++, D, Object Pascal, ADD 1 TO COBOL GIVING COBOL
and whatever other OO languages you care to think of....

Further idea: develop an OS with built-in garbage collection facilities.

Stewart.

--
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment. Please keep
replies on the 'group where everyone may benefit.

"Stewart Gordon" <> wrote
> While it was 1/2/04 2:26 pm throughout the UK, Michael Groys sprinkled
> little black dots on a white screen, and they fell thus:
> > Hello all,
> > I'm looking for collaborators to develop new object oriented operating
> > system.
> > As most of the software development had moved to the OO languages so
> > the OS must move towards OO OS.
> <snip>
>
> I suppose that would be a nice concept. All the better if it can be
> made compatible with C++, D, Object Pascal, ADD 1 TO COBOL GIVING COBOL
> and whatever other OO languages you care to think of....
>
> Further idea: develop an OS with built-in garbage collection facilities.

I've been trying to avoid this senseless thread, but this desperately needs to
be said. All of the cutesy ideas about OS design that keep cropping up: BEEN
DONE, FOLKS! Been done BETTER. Been done by more competent people. Been written
about in dozens of books and hundreds of articles. Can be found in herds through
judicious use of Google.

Time to move these naive sugar-cane-in-the-sky inspirations to a more
appropriate forum. Try comp.l337.kewl.kewl.kewl

Claudio Puviani

DeMarcus wrote:
>
> There is one really bad thing with object oriented languages:
>
> My view of objects and your view of objects may differ a lot.
> That's the beauty of plain C API:s. When I get the API from a
> supplier I wrap it within my objects seen from my point of view.
>
> Take threads for instance. I don't like the Java
> overload-thread::run()-style of threads. What does a typical
> thread class look like from your point of view? (or anyone else
> reading this)
>
> Best regards
> Daniel Marcus
>
>
> PS. I like your idea, but I may or may not like your view of
> objects.
>

It is indeed very important point,
because I want the new OS to be as programmer friendly as possible.
Still I think that it solvable problem.
First of all I think we can relatively easy define set of objects that
is managed by each module of OS.
A bit harder but still easy to define the objects' functionality.
The most problematic stage is to define the API.
For this purpose we can use Internet society (for example this forum).

And I want to ask people to write here their suggestions about the
set of classes and their api, that new OS must provide.

PS.
How do you like to see Thread class?
In any case we can provide several interfaces,
but their functionality must include the possibility of
execution of some method of users object, to allow user
to provide additional data to the newly created thread.

Best regards, Michael

To me a thread is a task that shall be executed, and most often
it's not an object. Therefore I'd like to see the threads as a
normal method that shall be run, or in this case, a callback
just as in pthreads. To clearify what I mean; I want to be able
to run an arbitrary method within an object just as I run it
normally, sending exaclty the parameters required for that method
and get the result whatever it is.

Let's say I have a class like this:

class Cafe : public Interface // explained later
{
public:

Coffe makeCoffe( bool sugar, bool milk );
Cake makeCake( int nStrawberries );
};

Then I certainly don't want the class to know anything about threads
(maybe reentrance though) meanwhile the user of it may want to run the
methods of it within different threads.

Now you think; "Hmm, callbacks in C++, this may be tricky with
method pointers to some base object. We'll easily run into some tacky
mesh of templates." But there's a way to solve it that I use today.
I use double dispatch for my thread callbacks. It's clean and simple,
BUT it demands that you conform to an Interface/Interaction-standard.

Now we create interactions:

class MakeCoffee : public Interaction
{
public:

// Parameters
bool sugar;
bool milk;

// Results
Coffee coffee;


virtual void executeOn( Interface* interface )
{
Cafe cafe = dynamic_cast<Cafe*>(interface);
if( cafe == 0 )
throw Exception();
coffee = cafe->makeCoffee( sugar, milk );
}
};

class Thread
{
public:

void run( Interface* interface, Interaction* interaction )
{
interaction->executeOn( interface );
}
};

int main( void )
{
Cafe cafe;
MakeCoffee makeCoffee;
Thread thread;

makeCoffee.milk = true;
makeCoffee.sugar = false;

thread.run( &cafe, &makeCoffe );
thread.wait();

if( makeCoffe.coffee.isGood() )
return 0;

return 1;
}


This is my view of threads. I don't know if anyone else like it.

Best Regards
Daniel Marcus





Michael Groys wrote:
>
>
> DeMarcus wrote:
>
>>
>> There is one really bad thing with object oriented languages:
>>
>> My view of objects and your view of objects may differ a lot.
>> That's the beauty of plain C API:s. When I get the API from a
>> supplier I wrap it within my objects seen from my point of view.
>>
>> Take threads for instance. I don't like the Java
>> overload-thread::run()-style of threads. What does a typical
>> thread class look like from your point of view? (or anyone else
>> reading this)
>>
>> Best regards
>> Daniel Marcus
>>
>>
>> PS. I like your idea, but I may or may not like your view of
>> objects.
>>
>
> It is indeed very important point,
> because I want the new OS to be as programmer friendly as possible.
> Still I think that it solvable problem.
> First of all I think we can relatively easy define set of objects that
> is managed by each module of OS.
> A bit harder but still easy to define the objects' functionality.
> The most problematic stage is to define the API.
> For this purpose we can use Internet society (for example this forum).
>
> And I want to ask people to write here their suggestions about the
> set of classes and their api, that new OS must provide.
>
> PS.
> How do you like to see Thread class?
> In any case we can provide several interfaces,
> but their functionality must include the possibility of
> execution of some method of users object, to allow user
> to provide additional data to the newly created thread.
>
> Best regards, Michael
>

"DeMarcus" <> wrote
>
> Let's say I have a class like this:
>
> class Cafe : public Interface // explained later
> [...]
>
> class MakeCoffee : public Interaction
>
> [...]
>
> class Thread
> {
> public:
>
> void run( Interface* interface, Interaction* interaction )
> {
> interaction->executeOn( interface );
> }
> };

Why be so intrusive? Classes shouldn't have to inherit from some arbitrary class
just to be usable in a given context. If you want to be able to call just about
anything, create a framework of functors that allow you to wrap regular
functions and method invocations and have your threads invoke the functor. Now,
the rest of the system isn't artificially coupled with your threading libraries
and you don't introduce a massively subjective view of "what threads really
mean".

Claudio Puviani

"Low coupling. It's not just for breakfast any more."

Claudio Puviani wrote:
> "DeMarcus" <> wrote
>
>>Let's say I have a class like this:
>>
>>class Cafe : public Interface // explained later
>>[...]
>>
>>class MakeCoffee : public Interaction
>>
>>[...]
>>
>>class Thread
>>{
>>public:
>>
>> void run( Interface* interface, Interaction* interaction )
>> {
>> interaction->executeOn( interface );
>> }
>>};
>
>
> Why be so intrusive? Classes shouldn't have to inherit from some arbitrary class
> just to be usable in a given context. If you want to be able to call just about
> anything, create a framework of functors that allow you to wrap regular
> functions and method invocations and have your threads invoke the functor. Now,
> the rest of the system isn't artificially coupled with your threading libraries
> and you don't introduce a massively subjective view of "what threads really
> mean".
>
> Claudio Puviani
>
> "Low coupling. It's not just for breakfast any more."
>
>

Yes, you're right. I have to go through my code and see what I really
though when I designed it. But our solutions are quite close ain't
they? I mean, if we remove the inheritance of Interface from class Cafe
and change MakeCoffee to

class MakeCoffe : public Functor
{
public:
MakeCoffe( void* instance );

virtual void execute( void )
{
dynamic_cast<Cafe*>(instance)->makeCoffe( sugar, milk );
}
};

and change Thread::run() to

void run( Functor* functor )
{
functor->execute();
}

ain't we then speaking almost the same language here?

I agree with your idea, I just have make sure I got it right to be able
to improve my framework.


Daniel Marcus


PS. Also to Michael Groys; seconds after I posted my message I realized
that my situation actually can be solved quite easy with the old Java-
overload-thread::run()-style as well.

DeMarcus wrote:
>
>
> Claudio Puviani wrote:
>
>> "DeMarcus" <> wrote
>>
>>> Let's say I have a class like this:
>>>
>>> class Cafe : public Interface // explained later
>>> [...]
>>>
>>> class MakeCoffee : public Interaction
>>>
>>> [...]
>>>
>>> class Thread
>>> {
>>> public:
>>>
>>> void run( Interface* interface, Interaction* interaction )
>>> {
>>> interaction->executeOn( interface );
>>> }
>>> };
>>
>>
>>
>> Why be so intrusive? Classes shouldn't have to inherit from some
>> arbitrary class
>> just to be usable in a given context. If you want to be able to call
>> just about
>> anything, create a framework of functors that allow you to wrap regular
>> functions and method invocations and have your threads invoke the
>> functor. Now,
>> the rest of the system isn't artificially coupled with your threading
>> libraries
>> and you don't introduce a massively subjective view of "what threads
>> really
>> mean".
>>
>> Claudio Puviani
>>
>> "Low coupling. It's not just for breakfast any more."
>>
>>
>
> Yes, you're right. I have to go through my code and see what I really
> though when I designed it. But our solutions are quite close ain't
> they? I mean, if we remove the inheritance of Interface from class Cafe
> and change MakeCoffee to
>
> class MakeCoffe : public Functor
> {
> public:
> MakeCoffe( void* instance );

Why you provide it as void* and not just Cafe*

> virtual void execute( void )
> {
> dynamic_cast<Cafe*>(instance)->makeCoffe( sugar, milk );
> }
> };
>
> and change Thread::run() to
>
> void run( Functor* functor )
> {
> functor->execute();
> }
>
> ain't we then speaking almost the same language here?
>
> I agree with your idea, I just have make sure I got it right to be able
> to improve my framework.
>
>
> Daniel Marcus
>
>
> PS. Also to Michael Groys; seconds after I posted my message I realized
> that my situation actually can be solved quite easy with the old Java-
> overload-thread::run()-style as well.
>
>

I also think that in the case of thread object as in the case of other
callbacks from OS to user app the best way will be to
handle them like the functors. Then programmer can easily provide his
class that will perform any task he wishes during the invocation
of the callback. (And he can store in that object any data he wants)

In addition we can provide template implementation of callback object
that will call some function of some object and provide it with
some argument, like following

template<class T, class A, class R=void>
class CallObj: public Thread
{
public:
typedef R (T::*F)(A&);
F m_f;
T* m_t;
A m_a;
CallObj(T* t, F f, const A& a)
: m_t(t), m_f(f), m_a(a)
{}
void run() {
(m_t->*m_f)(m_a);
}
};

class MyClass
{
public:
void print(const int& i) {
printf("i=%d\n", i);
}
};

int main() {
MyClass p;
CallObj<MyClass, const int> co(&p, &MyClass:rint, 10);
co.run();
return 0;
}

Michael.
PS. this compiles under g++.

Michael Groys wrote:
>
>
> DeMarcus wrote:
>
>>
>>
>> Claudio Puviani wrote:
>>
>>> "DeMarcus" <> wrote
>>>
>>>> Let's say I have a class like this:
>>>>
>>>> class Cafe : public Interface // explained later
>>>> [...]
>>>>
>>>> class MakeCoffee : public Interaction
>>>>
>>>> [...]
>>>>
>>>> class Thread
>>>> {
>>>> public:
>>>>
>>>> void run( Interface* interface, Interaction* interaction )
>>>> {
>>>> interaction->executeOn( interface );
>>>> }
>>>> };
>>>
>>>
>>>
>>>
>>> Why be so intrusive? Classes shouldn't have to inherit from some
>>> arbitrary class
>>> just to be usable in a given context. If you want to be able to call
>>> just about
>>> anything, create a framework of functors that allow you to wrap regular
>>> functions and method invocations and have your threads invoke the
>>> functor. Now,
>>> the rest of the system isn't artificially coupled with your threading
>>> libraries
>>> and you don't introduce a massively subjective view of "what threads
>>> really
>>> mean".
>>>
>>> Claudio Puviani
>>>
>>> "Low coupling. It's not just for breakfast any more."
>>>
>>>
>>
>> Yes, you're right. I have to go through my code and see what I really
>> though when I designed it. But our solutions are quite close ain't
>> they? I mean, if we remove the inheritance of Interface from class Cafe
>> and change MakeCoffee to
>>
>> class MakeCoffe : public Functor
>> {
>> public:
>> MakeCoffe( void* instance );
>
>
> Why you provide it as void* and not just Cafe*
>
>> virtual void execute( void )
>> {
>> dynamic_cast<Cafe*>(instance)->makeCoffe( sugar, milk );
>> }
>> };
>>
>> and change Thread::run() to
>>
>> void run( Functor* functor )
>> {
>> functor->execute();
>> }
>>
>> ain't we then speaking almost the same language here?
>>
>> I agree with your idea, I just have make sure I got it right to be able
>> to improve my framework.
>>
>>
>> Daniel Marcus
>>
>>
>> PS. Also to Michael Groys; seconds after I posted my message I realized
>> that my situation actually can be solved quite easy with the old Java-
>> overload-thread::run()-style as well.
>>
>>
>
> I also think that in the case of thread object as in the case of other
> callbacks from OS to user app the best way will be to
> handle them like the functors. Then programmer can easily provide his
> class that will perform any task he wishes during the invocation
> of the callback. (And he can store in that object any data he wants)
>
> In addition we can provide template implementation of callback object
> that will call some function of some object and provide it with
> some argument, like following
>
> template<class T, class A, class R=void>
> class CallObj: public Thread
> {
> public:
> typedef R (T::*F)(A&);
> F m_f;
> T* m_t;
> A m_a;
> CallObj(T* t, F f, const A& a)
> : m_t(t), m_f(f), m_a(a)
> {}
> void run() {
> (m_t->*m_f)(m_a);
> }
> };
>
> class MyClass
> {
> public:
> void print(const int& i) {
> printf("i=%d\n", i);
> }
> };
>
> int main() {
> MyClass p;
> CallObj<MyClass, const int> co(&p, &MyClass:rint, 10);
> co.run();
> return 0;
> }
>
> Michael.
> PS. this compiles under g++.
>


Yes, it sounds reasonable. Why I used void* (which to me feels scary in
a C++ environment) is because my brain went confused trying to put my
framework into a functor. I have one level higher of security where
some kind of functor are sent to an object, and it will only run if it
belongs to that object. A double dispatch thing. But that's my problem.



~ Daniel

"DeMarcus" <> wrote
> Yes, you're right. I have to go through my code and see what I really
> though when I designed it. But our solutions are quite close ain't
> they? I mean, if we remove the inheritance of Interface from class Cafe
> and change MakeCoffee to
>
> class MakeCoffe : public Functor
> {
> public:
> MakeCoffe( void* instance );
>
> virtual void execute( void )
> {
> dynamic_cast<Cafe*>(instance)->makeCoffe( sugar, milk );
> }
> };
>
> and change Thread::run() to
>
> void run( Functor* functor )
> {
> functor->execute();
> }
>

The point was to NOT inherit from something in the framework. Let me be more
explicit. You need a base functor class, say 'ThreadFunctor' that provides a
virtual method that's invoked by your threads (or eventually your thread pools
and other dispatch mechanisms, but let's not get ahead of ourselves). I usually
make that operator()(), but that's almost arbitrary in this context. Now, if you
want to invoke method 'doSomething' from class 'Whatever', you create a new
functor class, as follows:

class WhateverFunctor : public ThreadFunctor
{
public:
WhateverFunctor(Whatever & obj, int arg)
: m_obj(obj)
, m_arg(arg)
{
}

// other ctors, dtor, etc.

virtual void operator()()
{
m_obj.doSomething(arg);
}

private:
Whatever & m_obj;
int m_arg;
};

See? The original class, 'Whatever', doesn't get modified. It doesn't depend on
the threading framework and if you ever need to port it to another environment,
you can do it without maintaining different versions for the two (or more)
environments.

A test to see if inheritance is gratuitous is to ask if a class really IS a
variant of another. Is a coffee maker an interface? No. Is a coffee maker a
functor? No. If I want to bludgeon someone with a coffee maker, does that make a
coffee maker a mace? No.

Think of it another way. If I did want to use a coffee maker as an interface, a
mace, a lucky charm, and a decoration, would the class look like this?

class CoffeeMaker : public Interface, public Mace, public LuckyCharm, public
Decoration {};

It's extreme, but that's exactly what happens when someone inherits from a
totally unrelated class just to shoehorn the class into a particular usage.

Claudio Puviani