[Pharo-dev] Re: EU Citizen Initiative for consumers to have access to apps they purchased

2024-08-03 Thread James Foster via Pharo-dev
How would this impact software that is licensed on a subscription basis? What 
if some functionality in the application requires a server component. Is the 
vendor required to provide that server component forever? Or is the vendor 
prohibited from building applications that have a server component?

I have a deep suspicion of government regulation of business arrangements like 
this.

James

> On Aug 3, 2024, at 5:47 AM, David Mason  wrote:
> 
> There is currently a citizen initiative to get a law in place that makers of 
> software must not make the software become unusable after they end support.
> 
> While this is directly about games, it has implications for things like cars, 
> tractors, medical devices, and anything that has a significant software 
> component.
> 
> I encourage my EU friends and colleagues to consider signing and explaining 
> to their friends why it's important for them to sign even if they don't play 
> games.
> 
> Here's a video that explains it: https://www.youtube.com/watch?v=mkMe9MxxZiI
> 
> Here's tha petition: https://www.stopkillinggames.com/
> 
> Sorry this is a bit off-topic, but I think it's important to the entire 
> software industry.
> 
> ../Dave



[Pharo-dev] Re: A little post Why class number is an idiotic quality metric?

2024-02-10 Thread James Foster via Pharo-dev
For those that didn't write the post, here is a link…

https://pharoweekly.wordpress.com/2024/02/10/why-class-number-is-an-idiotic-quality-metric/

James

> On Feb 10, 2024, at 1:13 AM, stephane ducasse  
> wrote:
> 
> 
> https://wordpress.com/post/pharoweekly.wordpress.com/4226
> 
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> 06 30 93 66 73
> 
> "If you knew today was your last day on earth, what would you do differently? 
> ESPECIALLY if, by doing something different, today might not be your last 
> day on earth.” Calvin & Hobbes
> 
> 
> 
> 
> 



[Pharo-dev] Re: About removing class side initialization

2024-01-17 Thread James Foster via Pharo-dev
Stef,

Your comments brought to mind a few thoughts.

First, initialize methods should, in general, be idempotent; that is, running 
them repeatedly should not make further changes after the first run (along the 
lines of your mention of lazy initialization). For example, if a variable is 
nil then it should be set to an empty set; if it is already a set, don’t 
replace it.

Second, many packaging systems have scripts for pre-load, post-load, 
pre-remove, and post-remove. Instead of having initialize methods on a class, 
we could have scripts associated with a package. (Presumably a package will be 
a first-class object and have methods to handle these action.)

Third, following a model from upgrading databases, one would have a “version 
number” stored somewhere (perhaps a class variable) and scripts that upgrade 
and downgrade the version. Rerunning the “upgrade” would be idempotent since we 
would already be on the latest version.

As to the specific situation, yes, there is a problem with 
Behavior>>#initialize that arises from Behavior’s unique position where 
instances are classes and we have an unfortunate gratuitous polymorphism 
between instance initialization in which we are creating a new instance of 
Behavior (and giving it an empty method dictionary) and class initialization 
which is typically associated with _loading_ or _installing_ a class. Perhaps 
with a time machine the right solution would be separate names for these 
concepts (#initialize for instances, and #postLoad for classes). But really, 
the only place this is confusing is with Behavior, so maybe we should treat it 
as a special case rather than reaching for a general solution.

I think that rather than trying to prevent calling super initialize on classes 
(when failing to call super initialize on instances is a common bug) or trying 
to prevent an initialize from reaching Behavior>>initialize (by blocking it on 
the class side of Object), we should simply have Behavior>>initialize recognize 
its special position (and unique risk for confusion) by being idempotent. That 
is, if we already have a method dictionary, then there is no reason to do any 
further initialization; just protect the existing code with a check of “are we 
already initialized?” (Do the simplest thing that could possible work!)

So, while we could look at bigger solutions like package managers or image 
versions, we should just start by making Behavior>>#initialize smart enough to 
recognize its unique danger and handle the problem there. I don’t like the 
situation in which some initialize methods _must_ call super and some 
initialize methods _must not_ call super. 

In fact, I could imagine that there are some times when class initialization 
_should_ call super. Perhaps I have an abstract superclass that builds and 
caches a list of its subclasses (in GemStone this would be non-trivial). When a 
new subclass is added and the subclass is initialized, I want the super 
initialize method to be called so the superclass can reinitialize its cache. 
Perhaps this is a contrived case, but the point is that it isn’t really 
appropriate to put in a rule that you should not send super initialize.

Just some ideas and thoughts to let you know I’m reading your posts…

James Foster


> On Jan 17, 2024, at 12:37 PM, stephane ducasse  
> wrote:
> 
> Hi community
> 
> I would like to get use your ideas. 
> 
> Here is the case
> 
> Context: Class side initialize are not good.
>   We fixed a bug with guille today (should do a PR) this bug was breaking 
> some projects by changing the superclass of classes to Object. Radical!
> 
>   It was produced by the removal of DependentFields in Object and the 
> removal of the class side Object initialize method
>   Needed to initialize DependentFields (RIP).
> 
>   Doing so when a class was doing a super initialize it executes the 
> Behavior>>#initialize  (which reinitialize the class and its superclass) and 
> was not reachable before because blocked by Object class>>#initialize.
> 
> Two Situations. 
> 
>   When we do a class super initialize there are two cases
> 
>   Case 1. the super reaches Behavior>>#initialize and your class gets 
> killed.
>   Solution 1. Easy we will define a class side initialize method to 
> protect the execution of Behavior>>#initialize.
>   Ideally raising a warning so that people can find their problems.
> 
>   Case 2. 
>   You have a little hierarchy Root and Subclass1 Subclass2 classes
>   Root class defines an initialize method. 
>   
>   You should not redefine initialize in Subclass1 and do a super 
> initialize
>   else we get a double initialize. Not easy to grasp so I guess 
> that many people are making this mistake. 
> 
>   Solution 2. 
>   Cyril added a rule in a ReleaseTest (yes this is cool and we 
> should use more rules and not code by hand in the releaseTest)
>  

[Pharo-dev] Re: Fun with dates

2023-07-19 Thread James Foster via Pharo-dev
Not that this isn’t fun, but whenever anyone says “gues what it does," it 
reminds me of one of my favoriate quotes from Dijkstra in his 1972 ACM Turing 
Award Lecture, “The Humble Programmer”:

The competent programmer is fully aware of the strictly limited size of his own 
skull; therefore he approaches the programming task in full humility, and among 
other things he avoids clever tricks like the plague. In the case of a 
well-known conversational programming language I have been told from various 
sides that as soon as a programming community is equipped with a terminal for 
it, a specific phenomenon occurs that even has a well-established name: it is 
called “the one-liners”. It takes one of two different forms: one programmer 
places a one-line program on the desk of another and either he proudly tells 
what it does and adds the question “Can you code this in less symbols?” —as if 
this were of any conceptual relevance!— or he just asks “Guess what it does!”. 
From this observation we must conclude that this language as a tool is an open 
invitation for clever tricks; and while exactly this may be the explanation for 
some of its appeal, viz. to those who like to show how clever they are, I am 
sorry, but I must regard this as one of the most damning things that can be 
said about a programming language. 

— https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html


> On Jul 19, 2023, at 9:48 AM, Guillermo Polito  
> wrote:
> 
> Try to guess what each of the following lines of code do:
> 
> '''/5%9/$#=7*''*(?&&)58-,=93/1(0 1&<"1%?#$-::#)' asDate.
> 
> '*%!@$4*4#!$!.&0-";)7.<7?%(;  $535(0536.%#56&++''3!%0/' asDate.
> 
> '/-@+%3:3.''9"04=. @5+$;"& (6.-,?@*6"?43@@>*>:' asDate.
> 
> '1(%&0:19)) 7-?1.8;=?8+!&42-(?#>357).!=21603* 
> 6=?38.1**,//'':@663>.09!2%=!%%%2!>4'':@#/8!@==2>%651) 
> ',$*3,3''="0+0>:#14-8+(1@$&827%6-!)9-<>:"2+>&*39 !"(27' asDate.
> 
> '''"?. <>!@"2(%7#)0 )46+#'';=+"94?%)9 +!<.+!9,2*5("9$11-,?49 =6*77. 
> 0;/''%%/*' asDate.
> 
> '4.+@)3&11)."+.6=$&$0>5:5;:$,%5-+,4$0>")>4838''*2/' asDate.
> 
> '!7$:''!@0=)?0?<#&@*./0.:&?$?4 =<(7)@3$!:"$%%=""/?4*4=0?*$).,<+& 
> ::"8>:925$8!,2,95' asDate.
> 
> ' &+?!$3"(<*)1");35 $:&<"$!' asDate.
> 
> '>6(# %2736:-1#@@9%9''+"#?37''2,<3>8-*5"$2-6#''365++*8 &' asDate.
> 
> '?(2/=-@=@:4?/(3$3(8"&,!-2/&6&&' asDate.
> 
> '&?7+=''9,:$(430,3#/$4#866'';2/*,?):. -!#"7=?6:$3"5 -$/=0' asDate.
> 
> '3-;;=72@,9=%*.;+)74@7") 
> -&?(''7+!3-3<-0,<8:(,,;+5-$:81#&6''7830;"01+@>7<37''!(#/9"6%0?' asDate.
> 
> ';";5!9!,4/;25!0(<$4)''2"(2&-''4/>/.'')99(>><' asDate.
> 
> '03="9-/,*(;74"%@>=''91%>#=*=6*0/#02@?)0.' asDate
> 
> 
> G