On Sun, Dec 5, 2010 at 4:35 PM, Hartmut Goebel
<[email protected]>wrote:
> Hi,
>
Hi,
>
> still finding my way through the code, I really wonder about most of the
> stuff in utils.py:
>
> - prefixing functions with 'get_' is unpythonic and should be removed.
> This "get_" is useless data, since obvious in most cases.
>
> ok, I'll look it.
>
> - same for prefix "to_"
>
> ok if it's still easy to understand
>
> - get_sequence is not used at all and should be removed -- and I doubt
> it is useful
>
> Yes, it's a very old function that what used before the Class.id properties
(that manage the id unicity)
>
> - "print_date" has wrong name, since it does not print.
>
> Oups, yes, bad name.
>
> - For these "Pythnication" functions I really wonder if this is the
> best way.
>
> ?
>
>
> Which leads me to properties. I still did not exactly get, what they are
> since I did not find the place where they are used.
>
Where the properties dict are used? In fact thay are used nearly every where
in the part of code that manage creating the objects, link them and look if
they are correct. Then in the runnign part, they are not very useful anymore
(unless in the retention part of course).
>
> These properties seam to be very, very redundant.
>
Yes, because a lot of properties look the same after all.
> I Propose introducing property classes which hold a lot of the knowledge of
> the object types.
>
> 'execute_host_checks': BoolProperty(
> default=1, class_inherit= [(Host, 'execute_checks')]),
> 'status_update_interval': UnusedProperty(
> 'usage_text'= '...no longer used ...'),
>
> I did a test converting the properties in config.py to this syntax.
> Currently these are approx. 680 lines, the converted version is down to
> approx. 260 lines. This saves 60% of code for these area!
>
It can be a very cool thing if it's still easy to understand. It's the core
part of the configuration part and in all the data programming part. But
less lines can enhance readability, so it's can be a good thing.
> This change would save a lot of code elsewhere, since many test could be
> removed and test could be simplified. E.G. item.Item.pythonize() could be as
> short as:
>
> def pythonize(self):
> for name, prop in self.__class__.properties.items():
> try:
> old_val = getattr(self, name)
> new_val = old_val.pythonize()
> #print "Changing", old_val, "to", new_val
> setattr(self, name, new_val)
> except AttributeError , exp:
> #print self.get_name(), ' : ', exp
> pass # Will be catched at the is_correct momen
>
> Not really here, because the old_val is a string here (getattr get the
object property, and here it's sill a string, because pythonize is changing
all strings into real objects). But it can save some code elsewhere where we
look at 'default' existence in the properties entry.
> Another benefit would be, that semantics are much clearer then. E.g.
> required=True plus default-value is useless and unused properties do not
> need any other value but usage_text.
>
If I'm not wrong, there no required=True + default value, but the unused got
some useless properties entries.
> What do you think about this?
>
If it enhance the readability and is still easy to understand (let say not
so hard), it's ok, like Gerhard I'm ok to get this tool :)
> If you want to go this way, I happily hand over the small utility I wrote
> for converting the properties in config.py. And yes: I would do this for
> 0.4, since this vastly enhances readability, understanding and
> maintainability.
>
Ok to apply it, but let first look at what it impact before the 0.4
inclusion. More and more people are asking me when they can put the code in
production, and that why the 0.4 was mainly for. The actual code solve them
a lot of problems, they should be able to get it and begin to "scale easily"
;)
But if it's a 2 days job and it's easy to test, 0.4 can wait some few days.
Let look at how it look so.
Jean
> --
> Schönen Gruß - Regards
> Hartmut Goebel
> Dipl.-Informatiker (univ.), CISSP, CSSLP
>
> Goebel Consult
> Spezialist für IT-Sicherheit in komplexen
> Umgebungenhttp://www.goebel-consult.de
>
> Monatliche Kolumne: http://www.cissp-gefluester.de/
> Goebel Consult mit Mitglied bei http://www.7-it.de
>
>
>
> ------------------------------------------------------------------------------
> What happens now with your Lotus Notes apps - do you make another costly
> upgrade, or settle for being marooned without product support? Time to move
> off Lotus Notes and onto the cloud with Force.com, apps are easier to
> build,
> use, and manage than apps on traditional platforms. Sign up for the Lotus
> Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
> _______________________________________________
> Shinken-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
>
------------------------------------------------------------------------------
What happens now with your Lotus Notes apps - do you make another costly
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
_______________________________________________
Shinken-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shinken-devel
