Użytkownik "Michoo" napisał w wiadomości grup
dyskusyjnych:jt4hc2$trd$...@m...internetia.pl...
>> Odpowiedź oczywista: bo w trakcie działania ma tworzyć inne obiekty,
>> mające referencje do pól, a w szczególności do jego this.
>To nie jest problem, bo obiekt jest na etapie konstruktora już
>zainicjowany.

Michoo, wygląda na to że pogubiły się cytowania. Spróbuję uporządkować.

Ja twierdzę, że obiektu foo klasy Foo - niezależnie czy ma czy nie metodę
run() -- NIE DA SIĘ zastąpić wywołaniem nie-obiektowej funkcji
foofunc();

Uzasadniam: obiekt foo klasy Foo to nie tylko jego metoda run() (oraz ew.
jego konstruktor, lecz przecież dyskutowaliśmy o scaleniu run() z
konstruktorem). Obiekt klasy Foo to także wszystkie dane w polach obiektu,
ze szczególnym zwróceniem uwagi na te publiczne. Przykładowo nie jest tym
samym:

class Foo { public int n; int run() { return n++; } } ; // klasa

int foofunc() {return n++; } // funkcja

bo w drugim przypadku brak definicji n i jest to nietrywialne (nie da się
zastąpić deklaracją globalną int n; bo może istnieć wiele obiektów klasy
Foo, co nijak nie przekłada się na "wiele globalnych definicji int n").


PODSUMOWUJĄC - obiektowe podejście niekoniecznie jest zawsze najlepsze,
ale... jak już są obiekty, to nie ma na co marudzić.

slawek


--- Posted via news://freenews.netfront.net/ - Complaints to n...@n...net ---

do góry

Dnia Thu, 05 Jul 2012 21:01:33 +0200, slawek napisal:

>
> PODSUMOWUJĄC - obiektowe podejście niekoniecznie jest zawsze najlepsze,
> ale... jak już są obiekty, to nie ma na co marudzić.

Jak to marudzić. Rozstrzelać za takie pomysły bez zastanowienia.

Edek

do góry

Użytkownik "Edek Pienkowski" napisał w wiadomości grup
dyskusyjnych:jt4tpi$7u5$...@m...internetia.pl...
>Jak to marudzić. Rozstrzelać za takie pomysły bez zastanowienia.

Bo to będą obiekty, które będą pompowane przez sieć jako coś XML-owego, przy
tym w 99% będą binarne i na końcu, po paru(nastu) przekształceniach mają
zaistnieć jako elementy wizualnie widoczne. Po molierowsku dowiedziałem się
o mojej skłonności do GRAPPLE, czyli do gdybania o tym co i jak przez ponad
80% czasu. I tak na zdrowy rozum zauważyłem, że metod run() mam tyle samo co
konstruktorów... więc czemu by ich nie połączyć?! (Przy okazji zauważyłem
też wiele innych zadziwiających rzeczy, np. że więcej niż połowa rzeczy
jakie zrobiłbym bez UML byłaby i tak niepotrzebna do działania tego
programu.)

A dla odprężenia proponuję lekturę
http://xmpp.org/extensions/xep-0239.html - czyli specyfikację protokołu
przesyłania binarnych danych zgodnie z duchem, ideą itd. XML.

slawek

do góry

Dnia Thu, 05 Jul 2012 23:30:56 +0200, slawek napisal:

> Użytkownik "Edek Pienkowski" napisał w wiadomości grup
> dyskusyjnych:jt4tpi$7u5$...@m...internetia.pl...
>>Jak to marudzić. Rozstrzelać za takie pomysły bez zastanowienia.
>
> Bo to będą obiekty, które będą pompowane przez sieć jako coś XML-owego,
> przy tym w 99% będą binarne i na końcu, po paru(nastu) przekształceniach
> mają zaistnieć jako elementy wizualnie widoczne. Po molierowsku
> dowiedziałem się o mojej skłonności do GRAPPLE, czyli do gdybania o tym
> co i jak przez ponad 80% czasu. I tak na zdrowy rozum zauważyłem, że
> metod run() mam tyle samo co konstruktorów... więc czemu by ich nie
> połączyć?!

Odpowiedź brzmi: bo rozstrzelać. Ja sam należę do tych, którzy nie widzą
nic złego w (dosłowny kod):

...
new Obiekcik(i,j,k);
...

Przeyznaję, to trochę nietypowo wygląda, trochę jak wyciek. Ale tak nie
jest, cykl żcyia jest ściśle określony, bo konstruktor się rejestruje
w jakimś zbiorze po czym wykonuje pewną pracę kiedyś później, a na końcu
jest usuwany. Tę konstrukcję za to widziałem chyba tylko o Stroustupa:
ref = *new Obiekt();
Próbowałem tego użyć, ale przy pierwszym review skończyło się na pytaniach
"to tak można?" "no ale po co to?" więc zrezygnowałem.

(Przy okazji zauważyłem też wiele innych zadziwiających
> rzeczy, np. że więcej niż połowa rzeczy jakie zrobiłbym bez UML byłaby i
> tak niepotrzebna do działania tego programu.)
>
> A dla odprężenia proponuję lekturę
> http://xmpp.org/extensions/xep-0239.html - czyli specyfikację protokołu
> przesyłania binarnych danych zgodnie z duchem, ideą itd. XML.

Mam nadzieję, że to lżejsze od Higgsa.

Edek

do góry

Użytkownik "Edek Pienkowski" napisał w wiadomości grup
dyskusyjnych:jt51ta$7u5$...@m...internetia.pl...

>Mam nadzieję, że to lżejsze od Higgsa.

Ibidem jest opisany sposób zapisu pliku binarnego w postaci XML, ot po
prostu 01101 itd. powinno się zapisywać jako <zero/><one/><one/> etc.

Może wywołać oplucie monitora, zakrztuszenie się kanapką, rozlanie
kawy/czekolady/piwa na klawiaturę etc. (Przecież pisałem o odprężeniu?!)

Formalnie wygląda na "normalny" dokument nt. XML - np. ma uzasadnienie dla
i18n dla takiego zapisu - itp. itd.

do góry

Dnia Fri, 06 Jul 2012 08:17:23 +0200, slawek napisal:

> Użytkownik "Edek Pienkowski" napisał w wiadomości grup
> dyskusyjnych:jt51ta$7u5$...@m...internetia.pl...
>
>>Mam nadzieję, że to lżejsze od Higgsa.
>
> Ibidem jest opisany sposób zapisu pliku binarnego w postaci XML, ot po
> prostu 01101 itd. powinno się zapisywać jako <zero/><one/><one/> etc.
>
> Może wywołać oplucie monitora, zakrztuszenie się kanapką, rozlanie
> kawy/czekolady/piwa na klawiaturę etc. (Przecież pisałem o odprężeniu?!)
>
> Formalnie wygląda na "normalny" dokument nt. XML - np. ma uzasadnienie
> dla i18n dla takiego zapisu - itp. itd.

<dobre/><przecinek/><calkiem/><niezle/> ;)

Edek

do góry

Użytkownik "Edek Pienkowski" <e...@g...com> napisał:

> Tę konstrukcję za to widziałem chyba tylko o Stroustupa:
> ref = *new Obiekt();
> Próbowałem tego użyć,
Heh.
A ja konstrukcje Obiekt& ref = *new Obiekt(); (i podobne) stosuje namietnie
od lat gdzie tylko sie da i sobie chwale (bo zbliza nieco C++ do normalnosci).

> ale przy pierwszym review skończyło się na pytaniach
> "to tak można?" "no ale po co to?" więc zrezygnowałem.

Ci review-anci nadaja sie raczej do czyszczenia klawiatur :(

PS: Dziwne sa wybory dziesiejszej mlodziezy C++owej.

>> A dla odprężenia proponuję lekturę
>> http://xmpp.org/extensions/xep-0239.html - czyli specyfikację protokołu
>> przesyłania binarnych danych zgodnie z duchem, ideą itd. XML.

:) Naprawde nie moge wyjsc z "podziwu". Smieszne sa te "powroty rakiem"
do normalnosci z przeambicjnowanego XMLa (jak z kazdego silver bullet).

AK

do góry

W dniu 2012-07-05 16:27, slawek pisze:
> Użytkownik "Paweł Kierski" napisał w wiadomości grup
> dyskusyjnych:jt4588$o34$...@i...gazeta.pl...
>
>> W sumie najlepszy argument na "nie" - łatwo dopisać:
>> void foo()
>> {
>> Foo().run();
>> }
>
>> trudniej "rozkleić" istniejący konstruktor.
>
> Można też
>
> #define foo (Foo().run())
>
> Jednak argument o "rozklejaniu" jest chybiony - celem sklejenia mogłoby
> przecież być uniemożliwienie rozklejenia (i np. dwa razy wywoływania
> run() dla jednego obiektu).

W takim razie bym napisał:

class Foo
{
void run();
public:
Foo();
static void doFoo() {Foo().run();}
};

--
Paweł Kierski
n...@p...net

do góry

On Jul 5, 4:24 pm, "slawek" <h...@s...pl> wrote:
> Użytkownik "Andrzej Jarzabek"  napisał w wiadomości grup
> dyskusyjnych:7a3451d2-b497-461a-8a6e-b79d7ffda...@a1
6g2000vby.googlegroups.com...
>
> >Pewną dość oczywistą wadą 'uruchomienia przez konstruktor' jest brak
> >możliwości sensownego dziedziczenia po takiej klasie. W C++ dodatkowo
> >w takich przypadkach występuje problem z wywoływaniem funkcji
> >wirtualnych z konstruktora.
>
> Ale przecież konstruktor tej klasy może być sparametryzowany i jednocześnie
> domyślny konstruktor może być pusty. No problem.

Problem jest taki, że jeśli w klasie potomnej w konstruktorze wywołasz
ów pusty konstruktor, to tracisz dostęp do swojego 'run' - nie
skonstruujesz klasy bazowej dwa razy.

> Chyba vtable jest już wypełniona przed wejściem w blok {} konstruktora? Bo i
> niby czemu nie miałaby być?!

Powody mogłyby być, natomiast np. w C++ będzie to vtable dla aktualnie
konstruowanej klasy, a nie dla końcowego typu obiektu, który jest
konstruowany. Czyli jeśli masz klasę B, która wywołuje swój 'run' w
konstruktorze, tworzysz dziedziczącą po niej klasę D, która nadpisuje
funkcje wirtualne klasy B, to wywołania tych funkcji w 'run' nadal
wywołują funkcje zdediniowane dla B, nie te dla D. Nie mówiąc już o
pięknej okazji do wprowadzenia UB jeśli klasa jest abstrakcyjna.

W Javie jest inaczej, ale niekoniecznie lepiej: cała klasa
inicjalizowana jest przed konstrukcją i metody są wywoływane dla
ostatecznego typu, ale to znaczy, że trzeba przewidzieć
'nieskonstruowany' stan klasy: nie możesz np. założyć, że jakas
referencja jest nie-null, jeśli ustawiasz jej wartość w konstruktorze.

do góry

W dniu 2012-07-05 23:30, slawek pisze:
[...]
> A dla odprężenia proponuję lekturę
> http://xmpp.org/extensions/xep-0239.html - czyli specyfikację protokołu
> przesyłania binarnych danych zgodnie z duchem, ideą itd. XML.

Dobra, dobra:

<cytat>
Last Updated: 2008-04-01
</cytat>

RFC z 1.04 w różnych latach też są fajne 8-)

--
Paweł Kierski
n...@p...net

do góry