[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: Name change, more plan
From:       Nicolas Brodu <nicolas.brodu () free ! fr>
Date:       2000-03-18 16:22:44
[Download RAW message or body]

Stefan Westerfeld wrote:
> 
>    Hi!
> 
> The more I think about the new "easy" component C++ API, the more I think
> that it is not an issue of either this or the old. Probably the best way is
> really
> 
>    "easy" C++ API  |  aRtsbuilder/flow graph stuff
>  ------------------+--------------------------------
>               standard  C++ API

That would be fine. I can even reintroduce the 'component' keyword in the idl so
that the "easy C++" API is generated only for those objects.

> What exactly the target audience for the "easy" C++ API is, remains to be
> seen. However, what we can do now is: make sure that the standard C++ API

Audience for the "Easy C++". The idea was to do something like:
  http://www.kitware.com/vtkhtml/vtkdata/atoz.html
Ready to use components, their descriptions, etc... Then you just pick what
objects you need, connect them, and have a working C++ app. Of course, those
objects would also be available in artsbuilder.

> It seems that the "easy" C++ API isn't intended to take over all functionality
> of the standard C++ API, and that wouldn't be possible/nice either.

No, from your last mails on the list, more work needs to be done. I made the
changes because of this comment in a previous mail:
| with the component like syntax. But then, everything should be handled that
| way, and the other syntax should go away, to get things consistent again.
Obviously things are not yet consistent enough.

> But then, I think changing names back is a good idea.
> 
>    SimpleSoundServer_var x = SimpleSoundServer_base::_fromString("foo");
> 
> doesn't seem to be that intuitive. The same is valid for parameters and
[snip]

Well, it doesn't seem intuitive for a CORBA experienced developper to add
"_base" to the base class.
OTOH, for a CORBA-unaware C++ developper, 'Foo foo;' is much more clear than
'Foo_var foo = Foo::_create()' (and I use _create() here...)

> I'd suggest having:
> 
>    SimpleSoundServer_obj server;
> 
> as declaration for the "easy" C++ API, and
> 
>    SimpleSoundServer *server;
>    SimpleSoundServer_var server;
[snip]

I agree to change the name back for the reasons you mention here. However, what
about my initial proposal? That is, keep all the "standard" C++ API, but
put the Easy one in a namespace. That way, you just have to do:

  using namespace MCOPComponent;
  Foo foo;

And there you go for the easy stuff. Of course, you could still access ::Foo is
needs be.
It would solve the critic stability issue we have now, while allowing the "easy"
API to evolve at its own pace.

> 
> Nicolas, if you agree, would you make the required changes? (Please test
> that kdemultimedia still compiles afterwards). Or shall I do it?

Reversing the stuff in kdelibs is easy for me, from the snapshot just before my
changes. I think I still have one at home. I can also put the new C++ stuff in a
namespace and the 'component' keyword back in the idl to generate it.

I didn't check kdemultimedia the first time, because I didn't think about it!
If it's OK with you, I think it would be easier for you to reverse kdemultimedia
because you know what you just changed. Otherwise, I'll do it.

So what I'll do:
- Reverse to the old syntax by default in kdelibs.
- Add keyword and namespace.
- Have a look at kdemultimedia if you didn't do it already.

OK?

-- 
A shortcut is the longest distance between two points. (unknown author)

[prev in list] [next in list] [prev in thread] [next in thread]