Niech będzie sobie klasa (w czymkolwiek, niekoniecznie C++)

class Foo { Foo(){...}; run(){...} };

Obiekt tej klasy tworzymy sobie jako Foo foo = new Foo(); // czy jakoś tak,
nieważne

Obiekt istnieje, więc przychodzi czas na metodę run(), która jak sama nazwa
wskazuje (BASIC) robi to co robi.

I tu jest pytanie, a nawet dwa:

1. Czy nie wystarczyłoby zrobić copy-paste tego co ma run() w środku do
konstruktora i wy...ć [ref1] zbędne już run() ?

2. Czy metodę run() można wywoływać w konstruktorze (i dlaczego nie?)

Jeszcze raz - wywołanie konstruktora i run() są jedno-po-drugim, nigdy nie
będzie potrzeby rozdzielenia. UWAGA: podkreślam - niekoniecznie C++. Także
C#, Java, cokolwiek co lubicie.

TIA
slawek

[ad ref1] ... = rzuci

do góry

Dnia 04-07-2012 o 20:50:53 slawek <h...@s...pl> napisał(a):

> Niech będzie sobie klasa (w czymkolwiek, niekoniecznie C++)
>
> class Foo { Foo(){...}; run(){...} };
>
> Obiekt tej klasy tworzymy sobie jako Foo foo = new Foo(); // czy jakoś
> tak, nieważne
>
> Obiekt istnieje, więc przychodzi czas na metodę run(), która jak sama
> nazwa wskazuje (BASIC) robi to co robi.
>
> I tu jest pytanie, a nawet dwa:
>
> 1. Czy nie wystarczyłoby zrobić copy-paste tego co ma run() w środku do
> konstruktora i wy...ć [ref1] zbędne już run() ?
>
> 2. Czy metodę run() można wywoływać w konstruktorze (i dlaczego nie?)
>
> Jeszcze raz - wywołanie konstruktora i run() są jedno-po-drugim, nigdy
> nie będzie potrzeby rozdzielenia. UWAGA: podkreślam - niekoniecznie C++.
> Także C#, Java, cokolwiek co lubicie.
>
> TIA
> slawek
>
> [ad ref1] ... = rzuci

nie widzę, jaka właściwość jakiego języka wymuszałaby taki zapis,
podejrzewam inny powód:
obiekt foo ma sporo właściwości, które mają rozsądne wartości domyślne
ustawiane w konstruktorze, ale pomiedzy konstrukcją a foo.run() masz
możliwość skonfigurowania Sobie obiektu, jeśli jest to taki rzadki
wypadek, gdy domyślne ustawienia są nieoptymalne...


--
Jordan Szubert

do góry

Użytkownik "Jordan Szubert" napisał w wiadomości grup
dyskusyjnych:o...@a...home...

>nie widzę, jaka właściwość jakiego języka wymuszałaby taki zapis,

Mniejsza o zapis, rzecz jest nie w notacji, lecz w fakcie iż obiekt jest
konstruowany przez konstruktor, czyli dopiero po wykonaniu konstruktora
obiekt jest... skonstruowany. De facto C++ wywołuje wszystkie konstruktory
podobiektów oraz rodziców zanim wejdzie do body "naszego konstruktora" (więc
nasz obiekt ma wszystko co trzeba)...

ale - konstruktor może się sam-z-siebie wywołać (np. jakiś obiekt tymczasowy
się przypląta). I to jest problem, przynajmniej w C++. Ale czy są jakieś
języki wolne od tego?

>podejrzewam inny powód:
>obiekt foo ma sporo właściwości, które mają rozsądne wartości domyślne

Nie podejrzewaj. Klasa Foo jest zupełnie przykładowa, cudów w niej nie ma.
Po prostu rozpisałem sobie coś na klasy i... w każdej - chyba jednak -
powinien być run(), co doprowadza mnie do zdziwienia "czy to naprawdę
potrzebne, czy nie wystarczy sam konstruktor?" No bo i po co metoda run -
skoro klasa jak tylko się utworzy ma robić run - aż do destrukcji?

>ustawiane w konstruktorze, ale pomiedzy konstrukcją a foo.run() masz
>możliwość skonfigurowania Sobie obiektu, jeśli jest to taki rzadki
>wypadek, gdy domyślne ustawienia są nieoptymalne...

Różnica pomiędzy czymś takim (C++)

int main() { Foo foo = new Foo; delete foo; return 0; }

a czymś takim

int main() { Foo foo = new Foo; foo.run(); delete foo; return 0; }

Pierwszy zapis jest po prostu krótszy. Ponadto running czegoś jest po prostu
1:1 z istnieniem obiektu.

Rozkładające, w C++, byłoby {Foo foo = Foo();} , tzn. najpierw jest
tworzony tymczasowy obiekt Foo (przez wywołanie konstruktora), potem
następowałoby kopiowanie tymczasowego obiektu na foo... "zaszyte w
konstruktor run()" byłoby odpalane w mało przewidywalny sposób. Ale podobna
składnia w Javie wydaje się być znacznie bezpieczniejsza, bo { Foo foo = new
Foo(); } nie używa /obiektu/ foo, ale /referencji-do-obiektu-foo/, czyli w
C++ byłoby to { Foo& foo = Foo(); }

Z drugiej strony Java będzie pewnie miała mały problem - nie wiadomo kiedy
będzie niszczony obiekt foo (i czy w ogóle).

A ponadto - osobliwie ciekawe pytanie, raczej C++/C# - czy możliwe jest
destrukcja obiektu już w tego obiektu konstruktorze?

do góry

On 04.07.2012 22:34, slawek wrote:
> Różnica pomiędzy czymś takim (C++)
>
> int main() { Foo foo = new Foo; delete foo; return 0; }
>
> a czymś takim
>
> int main() { Foo foo = new Foo; foo.run(); delete foo; return 0; }
>
Foo().run();

--
Pozdrawiam
Michoo

do góry

Dnia 04-07-2012 o 20:50:53 slawek <h...@s...pl> napisał(a):
> 1. Czy nie wystarczyłoby zrobić copy-paste tego co ma run() w środku do
> konstruktora i wy...ć [ref1] zbędne już run() ?

Do takiego scenariusza IMO znacznie bardziej nada się lambda, a nie klasa.

> 2. Czy metodę run() można wywoływać w konstruktorze (i dlaczego nie?)

Doprecyzuj pytanie. Wywołać metodę w konstruktorze zawsze można.

> TIA
> slawek

Pozdrawiam -- Spook.

--
Używam klienta poczty Opera Mail: http://www.opera.com/mail/

do góry

W dniu 2012-07-05 02:16, Michoo pisze:
> On 04.07.2012 22:34, slawek wrote:
>> Różnica pomiędzy czymś takim (C++)
>>
>> int main() { Foo foo = new Foo; delete foo; return 0; }
>>
>> a czymś takim
>>
>> int main() { Foo foo = new Foo; foo.run(); delete foo; return 0; }
>>
> Foo().run();
>

Pytanie, dlaczego nie Foo::run(), czyli metoda statyczna, czyli zwykła
funkcja? Domyślam się, że z powodu dużego skomplikowania funkcji,
w szczególności dużo elementów stanu, czyli potrzeba w rozdzaju:
http://www.refactoring.com/catalog/replaceMethodWith
MethodObject.html

W C++ uważałbym na czas życia obiektu - lepiej nie przekazywać
zewnętrznym obiektom o dłuższym czasie życia nic związanego z this. Ale
tak samo byłoby w przypadku zwykłej funkcji.

Dodatkowo można jeszcze z takiego obiektu/funkcji zwracać wartość:

zamiast:
MyType foo(params);

class Foo
{
public:
Foo(params);
operator MyType(); // musi zwracać kopię - patrz wyżej
};

Można wtedy zamiast:

MyType myVar = foo(params);

pisać:

MyType myVar = Foo(params);

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

do góry

W dniu 2012-07-05 07:55, Wojciech "Spook" Sura pisze:
> Dnia 04-07-2012 o 20:50:53 slawek <h...@s...pl> napisał(a):
>> 1. Czy nie wystarczyłoby zrobić copy-paste tego co ma run() w środku
>> do konstruktora i wy...ć [ref1] zbędne już run() ?
>
> Do takiego scenariusza IMO znacznie bardziej nada się lambda, a nie klasa.

Zależy, jak skomplikowana funkcja.

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

do góry

Użytkownik "Michoo" napisał w wiadomości grup
dyskusyjnych:jt2mjk$hud$...@m...internetia.pl...

>Foo().run();

Ok, też można. Nie zrozumiałeś jednak pytania. Bo to co proponujesz to dalej
używanie metody run/execute/command/...

A chodziło o taką "filozofię", w której samo istnienie obiektu uruchamia
jego działanie.

Czyli nie ma potrzeby "mieć obiekt i potem kazać mu coś zrobić" - tylko
"obiekt robi coś, bo po prostu istnieje".

do góry

Użytkownik "Wojciech "Spook" Sura" napisał w wiadomości grup
dyskusyjnych:o...@s...wroclaw.optopol.
zawiercie...

>Doprecyzuj pytanie. Wywołać metodę w konstruktorze zawsze można.

Doprecyzuj "zawsze" - tzn. w jakich językach można.

Na razie wiem - z tego co napisałeś - że nie znasz ani jednego języka, w
którym to języku nie można byłoby.

do góry

In the darkest hour on Thu, 05 Jul 2012 07:56:56 +0200,
Paweł Kierski <n...@p...net> screamed:
>>> int main() { Foo foo = new Foo; delete foo; return 0; }
>>>
>>> a czymś takim
>>>
>>> int main() { Foo foo = new Foo; foo.run(); delete foo; return 0; }
>>>
>> Foo().run();
>
> Pytanie, dlaczego nie Foo::run(), czyli metoda statyczna, czyli zwykła
> funkcja? Domyślam się, że z powodu dużego skomplikowania funkcji,
> w szczególności dużo elementów stanu, czyli potrzeba w rozdzaju:
> http://www.refactoring.com/catalog/replaceMethodWith
MethodObject.html
>

Pytanie dlaczego nie jeśli po wykonaniu nie będzie potrzebny:
int Foo_run() {...}

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:233B ]
[ 08:40:57 user up 13220 days, 20:35, 1 user, load average: 0.01, 0.89, 0.19 ]

Things always look better when you can't see them. -- Craig Bruce

do góry