[Zope] Does anyone care whether we deprecate ZClasses?

[Andreas Jung]

--On Mittwoch, 6. April 2005 16:06 Uhr -0400 Jonathan Cyr <cyrj at cyr.info> 
wrote:

> Yoohoo,
>
> ZClasses are not an expert technology to use, they are an introduction to
> Zope... Just because I use a thing, doesn't mean I can support/maintain a
> thing.  I can read the list, and try to help folks with questions that
> I've experienced... that's the support that can be offered at my skill
> level.

There are better ways to learn Zope than by using ZClasses. They should no 
longer
be mentioned e.g. in the Zope Book.

>
> If that's not enough... fine...  drop ZClasses, then DTML (you know, its
> next)... and all the folks in this boat with me.

That's nonsense. Open-source is a giving and taking. Ok, you can demand 
something
*but* the resources of the people giving something to you are limited and 
restricted
by several constraints (company needs, personal time etc.). As said a bunch 
of times
earlier ZClasses help up the 2.8 release. Every software has its life-cycle 
it is sometimes
a good thing to drop old things over board *if* they tend to cause serious 
problems.
This is here the case. So my proposal was to deprecate them officially in 
2.8 with the
possibility to kick them in 2.10 or later. Read carefully ("possibility"). 
Means if they
do not hurt in 2.10 or 2.11 then could stay but ZClasses could be removed 
if major
resources would be necessary to fix them.

>
> ZC should decide whether the benefits of ZClasses for low-end developers
> match against the hurdles to keeping it with the newer Zope releases.  If
> they don't see a need for this skill-level type of tool in Zope's feature
> list, they will pay down the road... Growth is king, even for Zope, who
> grew this platform?  Growth means newbies, right?  What elements got Zope
> to where it is?  Could ZClasses be on that list?  Why?
>
> And seeing comments like...
>
> - "Move to Zope Python Products" - you cant see the skill differences
> between OOP & Zope's API vs. ZClasses
>
> - "Use the Archetypes/CMF/Plone setup" - UML training? the CMF API and
> Plone underpinnings, easy?

If you are a somewhat clever (I assume you are) than you should be able
to adopt these technologies with a resonable amout of time. Using AT
as an example is easy and *more* straight forward than using ZClasses
where you can run against the wall very easily. From the programmers 
experiences
these frameworks are the future and definitely not ZClasses.

>
> - "Maintain it yourself then" - Update very slick code within Zope's
> flexible and aging API, with ZODB API too?  Maintain it...Yeah sure, hows
> this afternoon.

See above....if you have a need or interest in keep ZClasses you could pay 
Jim
some USD to fix ZClasses for you. I don't see it as a responsibility to 
provide
backward-compatibility for all and everything for ages. It would be nice to 
have
that *but* our resources are limited - they are especially limited because 
I see
little interest of the community helping out in Zope areas where work must 
be done.
Means the active people in the Zope community have/try to do help out in 
many fields
restricting their time from serious Zope work.

-aj

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope/attachments/20050407/745475cd/attachment.bin