kloczek: SPECS multi-gnome-terminal.spec

[wrobell]

On Sat, Jan 12, 2002 at 06:13:15PM +0100, Jacek Konieczny wrote:
> On Sat, Jan 12, 2002 at 04:28:06PM +0100, Tomasz Kłoczko wrote:
> > Ano. Tylko kwestia w tym żeby sprawdzić czy rzeczywiście te pliki są w
> > konkretnym przypadku używane przez libIDL czy służyły jako template do 
> > wygenerowania kawałka w C z interfejsem wkompilowanym w aplikację.
> 
> Tomku, rozumiesz wogóle co to jest CORBA? Jedną z zalet tej technologii
Po pierwsze zauważ, że to co sugerujesz (niby niewinnie) tym pytaniem
nie ma miejsca. Kloczek nie stawia problemu źle. Po prostu nie zauważa
innego problemu, którego ja także do dzisiaj nie widziałem, a który
przez Ciebie został przedstawiony poniżej. Wyluzujmy emocje może...

> jest to, że różne języki programowania mogą współdzielić obiekty. A jak
> sobie wyobrażasz komunikację programu w języku skryptowym (który nie
> jest kompilowany) z obiektami zaimplementowanymi w C, gdy nie jest
> dostępna informacja o interfejsie tych obiektów?
I o to właśnie mi chodzi. Nigdy nie patrzyłem na to w ten sposób.
Moje pytanie jest następujące. Czy rzeczywiście skrypty[1] korzystają
bezpośrednio z plików .idl?[2] Jeśli tak, to zdaje mi się, że trzeba
_wszystkie_ pliki .idl poprzenosić z *-devel do normalnych pakietów.

> A może taki skrypt
> powinien wymagać *-devel? A to że teraz możemy nie mieć w PLD żadnego
> takiego skryptu, to nie powód, zeby *.idl traktować jak *.h .
> IDL to pliki nie tylko developerskie i nie ma sensu je jako takie na
> siłe szufladkować. Komu przeszkadza te parę pliczków? Chyba tylko Tobie.
Po co to nerwy...
Jak dla mnie pliki .idl zawsze były developerskie. Dzisiaj zdaje
się, że zmienię pogląd... Mógłbyś podać jakieś przykłady konkretne,
gdzie aplikacja bezpośrednio używa plików .idl?

    wrobell <wrobell w ite.pl>

[1] Pewne uogólnienie, ale wiadomo o co chodzi jak myślę.
[2] Zadaje to pytanie ponieważ np.: taka Java wymaga użycia
    programu idlj, który na podstawie plików .idl tworzy
    pliki z interfejsami. Taki dynamiczny język, a tak się
    trzeba bawić. Przez analogię wyobrażałbym sobie takie
    same zachowanie w przypadku Pythona...