If you're curious about the internals of Pmods and their implementation (given that that seems to be where this conversation has gone), I did a talk a few months ago on "Erlang Gotchas" that featured Tuple modules and the now-deprecated Pmods that covers how they work within Erlang: It starts with slide number 7: http://slides.sigma-star.com/view/Erlang%20Gotchas#/7
Maybe you'll find it helpful along your path of understanding some of Erlang's deep, dark secrets. -Jesse On Sat, Jul 5, 2014 at 2:04 PM, Jason Clark <[email protected]> wrote: > thanks that makes it a lot clearer > > > On Wednesday, July 2, 2014 7:53:56 AM UTC-7, Igor Clark wrote: >> >> Hey Jason, mihawk gave a great example there. Not sure if you're new to CB >> and/or Erlang, but I also found this really confusing when I started looking >> at CB. >> >> If you're at all like me it might help to know that the way the models >> work is using "parameterized modules", which (if I understand them >> correctly) are a way to pass state into a variable when you create it >> through parameters on a special "new" function in the module. >> >> They're kind of controversial in Erlang world as they bring an "OO-like" >> flavour that many dislike (and argue strongly against), and in fact were >> removed from the runtime a couple of versions ago, so there's not even much >> in the way of documentation that comes up in a search >> (http://myotherpants.com/2009/04/parameterized-modules-in-erlang/ gives a >> brief overview, and there are a few notes about them on Stack Overflow). >> >> "P-mods" are pretty core to CB's models though, as they allow >> "construction" of "objects" (really just structured variables with tuples in >> them under the hood) in a Rails-ish way, and so they're still supported in >> CB by using a "parse transform", which basically converts code using them to >> non-parameterized "normal" Erlang code. >> >> So the "new" "method" you're trying to call there is really a >> module:function call which requires the extra "constructor"-like arguments >> mihawk showed in the example in order to "initialize" the variable as a >> parameterized module. Once that's done and you have the p-mod variable in >> play, you can call the module's functions like "accessors" to get hold of >> the state variables being looked after by the p-mod. >> >> Like I said I found this really confusing to start because I was trying to >> get the whole Erlang stateless module:function thing in my head and this >> seemed to be contrary to that approach; what helped me was to grasp and >> remember that what one's really doing with the models (and also Requests and >> other CB constructed that have parameters in their module definitions) is >> using some syntactic sugar to help you deal with some state stuff in a more >> familiar way, if you're coming from e.g. Rails or Django or some other >> environment with an ORM. >> >> Hope this makes sense, and hope others will put me straight if I have >> anything wrong! >> >> Cheers >> Igor >> >> On Tuesday, July 1, 2014 11:15:03 PM UTC-4, mihawk wrote: >>> >>> hi, >>> >>> Attrs = [{username, "MyName"},{email "[email protected]"}], >>> M = boss_record:new(member, Attrs). >>> >>> M:username(). >>> M:email(). >>> >>> M1 = M:set(name, "MyName"). >>> M1:name(). >>> >>> M1:save(). >>> >>> >>> >>> >>> >>> >>> 2014-07-02 5:28 GMT+08:00 Jason Clark: >>>> >>>> how do i or can i access a model from the console >>>> say i make >>>> src/model/member.erl >>>> -module(member, [Id, Username, Email, Name, PasswordHash, Key, Status]). >>>> -define(SECRET_STRING, "Not telling secrets!"). >>>> -compile(export_all). >>>> >>>> %% @doc Returns the session identifier. >>>> session_identifier() -> >>>> mochihex:to_hex(erlang:md5(?SECRET_STRING ++ Id)). >>>> >>>> >>>> then in the console run >>>> member:new(). >>>> ** exception error: undefined function member:new/0 >>>> >>>> member:session_identifier(). >>>> ** exception error: undefined function member:session_identifier/0 >>>> any ideas >>>> im just following the an evening guide but swtched the ward_boss >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "ChicagoBoss" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to >>>> Visit this group at http://groups.google.com/group/chicagoboss. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/chicagoboss/9c60f373-bcf1-4308-b7fc-b7e7d1c36e8e%40googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> > -- > You received this message because you are subscribed to the Google Groups > "ChicagoBoss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > Visit this group at http://groups.google.com/group/chicagoboss. > To view this discussion on the web visit > https://groups.google.com/d/msgid/chicagoboss/ee5f5f5a-9675-47ad-a752-ae828c7c2ea4%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 || sigma-star.com || @jessegumm -- You received this message because you are subscribed to the Google Groups "ChicagoBoss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at http://groups.google.com/group/chicagoboss. To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/CAPTXyXe3ybyf3_XciLn0w79z8YZHHowxG4uAKYKn7c3ornMUvQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
