midgard_connection class API
-
Alexey Zakhlestine
midgard_connection class API
Thu June 18 2009 10:50:06 UTCI am working on test-suite for apis/php5 and trying to understand what
is the supposed behavior for midgard_connection class.
Currently it is a strange beast. In PHP it's API would look like this:
class midgard_connection
{
public function __construct();
public function open($name);
public function open_config(midgard_config $config);
public function connect($signal, $callback, $userdata = null);
public static function set_sitegroup($name);
public static function get_sitegroup();
public static function set_lang($langcode);
public static function get_lang();
public static function set_default_lang($langcode);
public static function get_default_lang();
public static function get_error();
public static function set_error($errorcode);
public static function get_error_string();
public static function get_user();
public static function get_request_config();
public static function set_loglevel($level, $callback = null);
public static function list_languages();
}
issues/questions:
1) why 4 first methods are non-static and others static?
2) constructor tries to be the singleton. that feels seriously wrong
to me. It shouldn't know anything about "other" objects.
I propose to convert it to be a canonical singleton. e.g.:
1) make constructor private
2) add "public static function getInstance()"
3) make all other methods non-static
I understand that it is a break of api, but as trunk is not in
production yet, we can live with this. On the bright side: this would
seriously ease transition to multi-connection mode if we ever need it.
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] midgard_connection class API
Thu June 18 2009 11:40:06 UTCAlexey Zakhlestin writes:
Hi!
> issues/questions:
> 1) why 4 first methods are non-static and others static?
Why constructor should be static?
> 2) constructor tries to be the singleton. that feels seriously wrong
> to me. It shouldn't know anything about "other" objects.
It was written for Ragnaroek. How many "other" objects we have there? None.
> I propose to convert it to be a canonical singleton. e.g.:
> 1) make constructor private
Why?
> 2) add "public static function getInstance()"
get_instance :) We can add getInstance, once ZE2 engine recognise more
than 24 alphabet letters ;)
Why we couldn't use superglobal for this?
> 3) make all other methods non-static
>
> I understand that it is a break of api, but as trunk is not in
> production yet, we can live with this. On the bright side: this would
> seriously ease transition to multi-connection mode if we ever need it.
Yes, multiple connections is something we would need.
* What to do with _MIDGARD_CONNECTION superglobal?
* How it should work in server context (httpd environment) ?
* How many corner cases we have?
midgard_object API is connection unaware almost, which means once
connection is associated with object it's unchanged and used internally,
but what to do with other API parts which require connection handler and
use
global one (e.g. replicator) ?
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] midgard_connection class API
Thu June 18 2009 12:45:05 UTCOn Thu, Jun 18, 2009 at 3:31 PM, Piotr Pokora<piotrek.pokora@gmail.com> wrote:
> Alexey Zakhlestin writes:
>
> Hi!
>
>> issues/questions:
>> 1) why 4 first methods are non-static and others static?
>
> Why constructor should be static?
that's nitpicking :-P
>
>> 2) constructor tries to be the singleton. that feels seriously wrong
>> to me. It shouldn't know anything about "other" objects.
>
> It was written for Ragnaroek. How many "other" objects we have there? None.
I am not speaking about historical reasons here. I am speaking about
"proper way" :-)
>> I propose to convert it to be a canonical singleton. e.g.:
>> 1) make constructor private
>
> Why?
Because that's the way canonical singletons work =)
http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way
>> 2) add "public static function getInstance()"
>
> get_instance :) We can add getInstance, once ZE2 engine recognise more
> than 24 alphabet letters ;)
> Why we couldn't use superglobal for this?
we can, but we need something to fill this superglobal. Currently it
happens in constructor. I propose to move it out of it (into static
method)
still, static-method is better because it is possible to have
lazy-initialization of connection
>> 3) make all other methods non-static
>>
>> I understand that it is a break of api, but as trunk is not in
>> production yet, we can live with this. On the bright side: this would
>> seriously ease transition to multi-connection mode if we ever need it.
>
> Yes, multiple connections is something we would need.
>
> * What to do with _MIDGARD_CONNECTION superglobal?
for now: fill it from ::get_instance() instead of __construct()
for future: probably we should just remove it
> * How it should work in server context (httpd environment) ?
for now: everything stays the way it is
for future: we can think of something like "default" connection and
use it for system-objects
> * How many corner cases we have?
that's what I am trying to understand by writing tests ;)
current code has a bunch of strange effects in cli-mode. that's why I
am trying to understand logic behind current code.
> midgard_object API is connection unaware almost, which means once
> connection is associated with object it's unchanged and used internally,
> but what to do with other API parts which require connection handler and
> use global one (e.g. replicator) ?
Well, I guess we will need to rewrite replicator to be aware, that
there might be situation, when we have several connections. Anyway,
we'll be able to think of it later
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] midgard_connection class API
Thu June 18 2009 13:15:05 UTCI want to move to this API instead:
class midgard_connection
{
public static function get_instance()
{
if (empty($_MIDGARD_CONNECTION))
$_MIDGARD_CONNECTION = new midgard_connection();
return $_MIDGARD_CONNECTION;
}
private function __construct();
public function open($name);
public function open_config(midgard_config $config);
public function connect($signal, $callback, $userdata = null);
public function set_sitegroup($name);
public function get_sitegroup();
public function set_lang($langcode);
public function get_lang();
public function set_default_lang($langcode);
public function get_default_lang();
public function get_error();
public function set_error($errorcode);
public function get_error_string();
public function get_user();
public function get_request_config();
public function set_loglevel($level, $callback = null);
public function list_languages();
}
Any objections?
Changes required to be implemented in MidCOM should be trivial.
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] midgard_connection class API
Thu June 18 2009 13:20:05 UTCAlexey Zakhlestin writes:
Hi!
>>> 2) constructor tries to be the singleton. that feels seriously wrong
>>> to me. It shouldn't know anything about "other" objects.
>> It was written for Ragnaroek. How many "other" objects we have there? None.
>
> I am not speaking about historical reasons here. I am speaking about
> "proper way" :-)
Sure, I am just trying to point that it was not build for strict vinland+.
>>> I propose to convert it to be a canonical singleton. e.g.:
>>> 1) make constructor private
>> Why?
>
> Because that's the way canonical singletons work =)
> http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way
Hardly see it with our purpose. Class is not created by user per request.
Real connection is.
> we can, but we need something to fill this superglobal. Currently it
> happens in constructor. I propose to move it out of it (into static
> method)
> still, static-method is better because it is possible to have
> lazy-initialization of connection
How do you see it in server context?
>> * What to do with _MIDGARD_CONNECTION superglobal?
> for now: fill it from ::get_instance() instead of __construct()
> for future: probably we should just remove it
And follow ugly $GLOBALS['_MIDGARD_CONNECTION'] pattern?
>> * How it should work in server context (httpd environment) ?
> for now: everything stays the way it is
> for future: we can think of something like "default" connection and
> use it for system-objects
Still, default connection must be initialized before user code is executed.
And some pointer to it must be available from any place.
>> * How many corner cases we have?
>
> that's what I am trying to understand by writing tests ;)
> current code has a bunch of strange effects in cli-mode. that's why I
> am trying to understand logic behind current code.
Logic is unchanged since Midgard 1.2.5.
"Hide connection pointer and do not use it directly with API"
>> midgard_object API is connection unaware almost, which means once
>> connection is associated with object it's unchanged and used internally,
>> but what to do with other API parts which require connection handler and
>> use global one (e.g. replicator) ?
>
> Well, I guess we will need to rewrite replicator to be aware
It's not about rewriting. Problem is that replicator (for example)
doesn't accept connection explicitly.
What I am thinking about is connections pool managed by user. So the
default (and superglobal) one is set by user and application. But this
brings many critical cases. For example live and staging sites'
connections will be available in the same pool. Of course, it's not
dangerous if user knows what to do and use server for his own.
But this might be very dangerous on servers which hosts many databases
and sites.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] midgard_connection class API
Sun June 21 2009 17:20:05 UTCAlexey Zakhlestin writes:
Hi!
> I want to move to this API instead:
>
> class midgard_connection
> {
What about final class?
Private constructor for underlying GObject will be a headache sooner or
later.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] midgard_connection class API
Mon June 22 2009 07:00:07 UTCOn Sun, Jun 21, 2009 at 9:10 PM, Piotr Pokora<piotrek.pokora@gmail.com> wrote:
> Alexey Zakhlestin writes:
>
> Hi!
>
>> I want to move to this API instead:
>>
>> class midgard_connection
>> {
>
> What about final class?
sure. that would make sense
> Private constructor for underlying GObject will be a headache sooner or
> later.
well… that has to be proven ;)
private constructor is extremely useful for clean singleton api.
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] midgard_connection class API
Mon June 22 2009 10:30:10 UTCAlexey Zakhlestin writes:
Hi!
>> Private constructor for underlying GObject will be a headache sooner or
>> later.
>
> well… that has to be proven ;)
> private constructor is extremely useful for clean singleton api.
Is there any real good reason for private constructor in final class?
Constructor should be responsible for underlying object initialization.
I know that get_instance() would do the same, but I would like to avoid
paranoid checks and validations.
Besides, singleton pattern, seems to be ( at least for me ) a problem
for multiple connections implementation.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] midgard_connection class API
Mon June 22 2009 11:10:08 UTCOn Mon, Jun 22, 2009 at 2:19 PM, Piotr Pokora<piotrek.pokora@gmail.com> wrote:
> Alexey Zakhlestin writes:
>
> Hi!
>
>>> Private constructor for underlying GObject will be a headache sooner or
>>> later.
>>
>> well… that has to be proven ;)
>> private constructor is extremely useful for clean singleton api.
>
> Is there any real good reason for private constructor in final class?
> Constructor should be responsible for underlying object initialization.
it still would be responsible for object initialization. it just won't
be possible to call constructor directly. we'll be using
get_instance() instead.
> I know that get_instance() would do the same, but I would like to avoid
> paranoid checks and validations.
>
> Besides, singleton pattern, seems to be ( at least for me ) a problem
> for multiple connections implementation.
Idea is to make everything in 2 steps:
1) make a __clean__ object-oriented implementation which is
semantically similliar to current code
2) use result of step #1 as a base for multiple connection implementation
singleton is usefult for step #1. for step #2 we would convert it to
factory (with minimal efforts)
p.s. working on the patch right now
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
-
Re: [midgard-dev] midgard_connection class API
Thu June 25 2009 20:16:50 UTCAlexey Zakhlestin writes:
Hi!
> Idea is to make everything in 2 steps:
> 1) make a __clean__ object-oriented implementation which is
> semantically similliar to current code
> 2) use result of step #1 as a base for multiple connection implementation
>
> singleton is usefult for step #1. for step #2 we would convert it to
> factory (with minimal efforts)
>
> p.s. working on the patch right now
I think we must forget about $_MIDGARD_CONNECTION superglobal.
Or at least, about such, used as "a pointer" to midgard connection.
Not sure yet, but I am afraid there's implicit copy made, and we have
random memory
instead of real underlying GObject pointer.
Piotras
_______________________________________________
dev mailing list
dev@lists.midgard-project.org
http://lists.midgard-project.org/mailman/listinfo/dev -
