Re^2: Modules design pattern: abstraction vs incarnation (providing not so static data)

hello haj and thanks for looking at my long post,

did you also followed links I provided? Forget for the moment my Game::Term project and focus on the Perl::Teacher one.

In Perl Automateaching -- part 1: brainstorming I presented the idea and I asked for suggestions on the implementation (how to judge perl documents) while in automateaching -- part 2: proof of concept I sketched out some viable approach to accomplish my task.

In my mind Perl::Teacher and all its classes are the teaching framework and must be written by me. This is what I named abstraction in this post.

No one line of code has stil been wrote for the Perl::Teacher module, so I have really took no techincal decisions at the moment, only the decision to process perl documents using PPI (ie: no code given into STDIN).

By other hand all lessons contained in courses can be written as separated modules by anyone. This is what I named incarnation in this post. So in the future peraphs haj will publish on CPAN Perl::Teacher::Course::EN::PerlIntro and this will contain Perl::Teacher::Course::EN::PerlIntro::01_safetynet and Perl::Teacher::Course::EN::PerlIntro::02_strictures and so on.

I hope the above satisfies your Are users supposed to write their own modules? question.

I presented my doubts about how to design this Perl::Teacher class and its interface in Module design for loadable external modules containing data and shown a brief example in Re^2: Module design for loadable external modules containing data

That said you are right to challange my point of view, and you are right when saying that objects are the incarnations all correct but does not change the point, or at list my point of view.

> Also, you seem to use scripts to store particular objects.

Here I dont follow you: where this sentence comes from? If from my post I must have wrote something in the very wrong way.

About OO frameworks:

> You might fare better if you decide to embrace them as soon as they help to solve your problem. I am pretty sure that almost no one needs to use all the features of Perl itself, yet many of us are Perl fans, and quite happy with it.

Well.. you turned the example in a nice way :) and yes, erase the all word from my sentence and will be the same of your. I will embrace them with happines when they help me in some way. Read above posts: I dont see any gain using roles.

I hope the above clarify your doubts, hoping now you can clarify mines :)

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

Comment on Re^2: Modules design pattern: abstraction vs incarnation (providing not so static data) Select or Download Code

Replies are listed 'Best First'.
Re^3: Modules design pattern: abstraction vs incarnation (providing not so static data) by haj (Vicar) on Nov 20, 2020 at 21:46 UTC
I had a glance at the other articles when they appeared and re-read them before answering. First of all it is a bit of a misnomer: Your goal is not to actually teach: you want to present exercises and evaluate responses. Teaching needs a storyline, a concept of independent modules doesn't help with that. Your second article contains 460 lines of code but not a single line of POD - sorry, I didn't spend time to walk through that. It doesn't give the impression of No one line of code has stil been wrote. I almost suspected that you aren't aware of the technical decisions you already made. I don't mind PPI - that's what I'd call an "internal affair". But there are others: You define courses and lessons as Perl modules. This is weird. Both courses and lessons are mostly data, in particular text, and not code. I don't believe that Perl modules are the best format to write lessons and exercises. You have each course to be a separate class, inheriting from your base class. Why? Why not different objects of a class you're providing? For this particular decision, I might be able to hallucinate the problem which you actually want to solve: You want authors of courses and lessons to be able to distribute their work. I don't know whether that is what brought you to the idea to use modules and CPAN, but CPAN would allow to "install" different courses by their name, therefore offering some method for distribution. As far as I'm concerned, I'm out: I don't have a CPAN account. You claim that you don't need to separate logic from presentation because you have mainly Perl data. Well, that's a direct consequence of the previous decision, isn't it? You surely know that web applications usually mix static data (templates) with database data, XML documents, and other dynamic data. The value comes with these dynamic data, not unlike to your situation. You dislike the idea to have external, yaml or json, files containing the data to be served. That's a decision against technical solutions, but with a rather lame reasoning. It isn't you who writes the courses, right? Do you have enough authors who share your preferences? So, how did I guess that you use scripts to store objects? You wrote: I have designed it to have incarnations (game scenarios in this case) as standalone scripts and this approach lead me to shell out when changing the current scenario. If you can't get a scenario's attributes without running a script, then I guessed the script stores this scenario's data. This may be wrong, or at least irrelevant. And finally, about OO frameworks: I didn't mention roles, and I didn't even have them in mind. All problems can be solved just fine without roles, but roles can bring elegance by avoiding boilerplate code. But Perl's OO frameworks have a lot more to offer. The issue is that there are too many of them :)	[reply]
Re^4: Modules design pattern: abstraction vs incarnation (providing not so static data) by tobyink (Canon) on Nov 21, 2020 at 17:56 UTC
"But Perl's OO frameworks have a lot more to offer. The issue is that there are too many of them :)" There are only three, and they play pretty nicely together. Moose Moo Class::Tiny The others do not exist. Or we can pretend they don't anyway. toby döt ink	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.


Come for the quick hacks, stay for the epiphanies.
	PerlMonks