when Task returns compact subsidiary object Workspace, instantiation fails

[mengwong]

Following up on our object caching discussion on #duckduckgo, I have a concrete case of a compact representation being returned by Asana.

A Task refers to a Workspace, but because we are working with a compact representation, that Workspace has only "id" and no "name". Those attributes are required, and cause instantiation failure of the Task.

Arguably, by returning compact objects, the Asana API implicitly encourages object caching.

I understand that over the course of a long-lived session, an object cache is risky due to the likelihood of object mutation at the server.

During a short-lived session, this risk is lower. As we discussed, some sort of plugin architecture could allow the calling application to choose to use a session-scoped object cache to easily handle compact responses by returning the existing object (if it exists).

Alternatively, we could permit WWW::Asana objects to require only the "id" attribute, and use lazy loading for the other attributes. The lazy loader would be responsible for retrieving the expanded version of the object.

Maybe the plugin could realize some combination of both approaches.

>>> new_from_response()
WWW::Asana::Task->new_from_response called with
 -      workspace
 -      parent
 -      response
 -      name
 -      projects
 -      due_on
 -      client
 -      created_at
 -      assignee
 -      notes
 -      modified_at
 -      id
 -      completed_at
 -      completed
 -      assignee_status
 -      followers at ../p5-www-asana/lib/WWW/Asana/Role/NewFromResponse.pm line 27.
>>> new_from_response()
WWW::Asana::Workspace->new_from_response called with
 -      client
 -      response
 -      id at ../p5-www-asana/lib/WWW/Asana/Role/NewFromResponse.pm line 27.
(()) calling WWW::Asana::Workspace->new(client WWW::Asana=HASH(0x7ff4ba526b30) response WWW::Asana::Response=HASH(0x7ff4bc3175c0) id 1404297026930)
Missing required arguments: name at (eval 1508) line 31.